Skip to main content
The dashboard’s Observability page shows how your gateway usage is behaving: health, throughput, and speed, separate from billing (which lives under Usage). It’s built to answer operational questions: Is my traffic healthy? What’s slow? Why are requests failing? How close am I to a rate limit?
Observability is dashboard-only. There is no observability API; everything described here is viewed in the dashboard, not pulled programmatically.

​
Content-free by design

Omnia captures the shape of each request (timing, token counts, the names of tools called, and status) but never your prompts or the model’s responses. Omnia is a gateway, not a data product. This applies everywhere in observability, including the per-request detail view. There are exactly two exceptions, both explicit and yours to make: response caching (retains responses so identical repeats serve at a discount) and request logging (retains full conversations so you can browse, export, and curate them into fine-tuning datasets). Both are opt-in workspace settings, off by default; nothing is retained while they’re off.
Because telemetry is content-free, observability can’t help you debug the content of a prompt or completion; it can only tell you about the request’s timing, token counts, tool names, and status. Log prompt/response content on your own side if you need it.

​
Headline stats

At the top of the page, the headline stats summarize health at a glance over the selected window:

Success rate

Share of requests that succeeded.

Requests

Total request volume over the window.

Latency p90

End-to-end latency at the 90th percentile.

TTFT p90

Time to first token at the 90th percentile.

Output speed

Generation throughput in tokens per second.

Errors

Count of failed requests over the window.

Avg tokens / request

Average token count per request.

Total tokens

Total tokens processed over the window.

​
Charts

Time-series charts render over windows from 15 minutes to 90 days, so you can zoom from a live incident out to long-term trends:
  • Requests: volume over time.
  • Errors: failed requests over time.
  • Latency: p50 / p90 / p99 percentiles.
  • TTFT: time to first token.
  • Tokens: token volume over time.
  • Output speed: generation throughput in tokens per second.

​
Errors by cause

When requests fail, the Errors by cause breakdown shows why, grouping failures into categories (rate limits, timeouts, and upstream errors) so you can act on the actual cause instead of just seeing an aggregate error rate. Map these categories back to the specific status codes in Errors: rate limits are 429, timeouts are 408, and upstream errors are 502.

​
Per-model breakdown

A per-model table breaks the same metrics down by model, so you can spot which model is slow, erroring, or driving your token volume, rather than reading a blended average across all of them.

​
Per-key breakdown

The same table exists per API key: which app, team, or environment is driving traffic, errors, and cache savings. Key names come from your key list; a key deleted since the traffic ran still shows (as “deleted key”) so history never loses attribution.

​
Request labels: tags and trace ids

Label any request with two optional headers. No SDK changes, works from any OpenAI client via extra_headers:
  • X-Omnia-Tag: a short label (letters, digits, _ : . -, max 64 chars; lowercased). Tagged traffic gets its own Per-tag usage table, tag chips in the request log, and a tag filter: segment by feature, customer, or environment.
  • X-Omnia-Trace-Id: group the steps of a multi-request agent run; shown in the request detail.
These are labels, not content: invalid values are silently dropped, and neither header is ever forwarded upstream. Your SDK’s User-Agent is also recorded (truncated) so you can spot which client version is producing errors. For traffic you never tagged, opt-in request logging adds auto-detected segments, grouping by system-prompt family, retroactively, with zero setup. Tags stay the deliberate override, and the two compose.

​
Finish reasons

A Finish reasons card breaks down how responses ended over the window: stop (natural), tool_calls, and, highlighted amber, length, meaning the response was truncated by max_tokens. A rising length count is the classic silent failure: responses look successful but are cut off mid-thought. Raise max_tokens or tighten prompts when you see it.

​
Alerts

Get notified instead of finding out later: Settings → Workspace → Alerts (owner/admin): Checks run every 5 minutes; each alert kind notifies at most once per hour. Error/latency alerts require a minimum number of requests in the window (default 20) so a single failed request never pages you. Notifications go to the workspace owner’s email and, optionally, an HTTPS webhook that receives {kind, value, threshold, detail, workspace, firedAt}.

​
Request log

The request log lists individual requests. Click any request to open its full, content-free detail:
Total latency, the provider-vs-gateway latency split (how much time was spent at the provider versus in the gateway), TTFT, and output speed.
Token counts for the request.
The names of any tools the request called. Names only, never arguments or results.
How close the request ran to the model’s rate limits; see Rate limits for how to act on this.
The request’s outcome status.
Whether the request was served by one of your fallback models, and which model it fell back from. Fallback-served requests also show a shuffle icon in the request list.
The request log is content-free and does not show the provider’s request id to you. If you need to reference a specific upstream failure with support, use the request id included in the 502 error message (see Errors).

​
Retention

You choose how long telemetry is retained, from 7 up to 90 days. Data older than your configured retention window is automatically deleted.

​
Dedicated endpoints

Each dedicated endpoint has its own observability page. It shows the same traffic and latency charts described here, and adds capacity and replica metrics so you can see how your reserved capacity is holding up under load.