Logs - Gatelit

The gateway logs every request to Supabase. You can view, filter, and search logs in the dashboard under Logs.

What’s logged

Field	Description
Request ID	Unique identifier — use for debugging specific requests
Timestamp	When the request was received
Model	The model that responded (may differ from requested if fallback triggered)
Status	`success` or `error`
Auth mode	`Bearer`, `GatelitSigned`, or `GatelitKey`
User / Org	The authenticated subject and organisation
Tokens	Input, output, and total token counts
Cost	Estimated cost in USD
Latency	Total round-trip time in milliseconds
Prompt ID	Which saved prompt this request was linked to
End user ID	The `endUserId` passed in the request
Metadata	The `metadata` tags attached to the request (shown as `key=value` chips)

Filtering

Filter logs by:

Date range — last hour, 24h, 7d, or custom
Status — success or error
Model — filter to a specific provider/model
Org — filter by organisation (admin only)
End user — filter by the endUserId header value
Metadata — filter by tags on the request’s metadata field. Each condition picks a key and an operator (equals, contains, exists, doesn't exist, is empty, is not empty); add multiple conditions with Add condition — they are combined with AND. Example: environment + equals + production, plus feature + contains + summar
Search — full-text search across request bodies and responses

Streaming view

The logs page supports a live streaming view — new requests appear as they’re logged, useful for debugging during development.

Cost tracking

The gateway estimates cost using the model catalog’s pricing data. This is an estimate, not billing-grade — use your provider’s dashboard for exact numbers. Cost is calculated as:

cost = input_tokens × input_price_per_1k + output_tokens × output_price_per_1k

Prices are stored in the model catalog and updated when the catalog syncs.

Request body inspection

Click any log entry to see the full request and response payloads. This is useful for:

Debugging prompt variable interpolation
Inspecting structured output results
Verifying fallback chain behaviour
Checking what the gateway sent to the upstream provider

Metadata

Requests that include a metadata field (see chat completions) show their tags as key=value chips on the log row, with the full set in the expanded detail. The metadata filter matches one or more tags. Use Add condition to chain multiple tag filters — all conditions must match (AND). Each condition has an operator:

Operator	Matches when
`equals`	The tag’s value equals the given value (numbers and booleans match their typed form — `retry_count` + `equals` + `2` finds `"retry_count": 2`)
`contains`	The tag’s value contains the given text (substring, any tag type)
`exists`	The tag key is present, regardless of value
`doesn't exist`	The tag key is absent
`is empty`	The tag key is present with an empty-string value
`is not empty`	The tag key is present with a non-empty value

Notes:

contains treats % and _ as wildcards (SQL ILIKE semantics)
Keys with special characters (dots, quotes, spaces) can only be used with equals — the other operators address keys as a single path segment
Conditions that are only partially filled in (e.g. equals without a value) are ignored until completed

Fallback trail

When a request had a fallback chain, the expanded log entry shows the fallback trail: every model attempted, its outcome (success / failed / skipped), the error class and HTTP status, and latency. This makes it easy to see exactly why the primary failed and which model eventually answered.

Retention

Logs are stored in Supabase. Retention depends on your Supabase plan and database size. For high-volume deployments, consider archiving older logs to external storage.

​What’s logged

​Filtering

​Streaming view

​Cost tracking

​Request body inspection

​Metadata

​Fallback trail

​Retention