Observability
Usage and incidents
Every request produces a usage record. Records are queryable in the console and retained according to the policy you configure.
recorded fields
- Requests
- by route, API key, provider, model, owner
- Tokens
- input, output, cached, reasoning
- Latency
- average, p95, time to first byte
- Errors
- by failure class and upstream status
- Failovers
- per route and per attempt
- Health
- per credential, live state
dashboard (sample)
last 24h- requests
- 1,284,930
- error rate
- 0.31%
- p99 latency
- 1.42s
- tokens
- 48.2M
+4.1%
-0.12%
+0.04s
+6.3%
latency distribution
| target | share | errors | state |
|---|---|---|---|
| openai / gpt-6-sol | 52% | 0.18% | serving |
| anthropic / claude-sonnet-5-5 | 31% | 0.24% | serving |
| bedrock / claude-opus-5-5 | 14% | 1.10% | degraded |
| azure / gpt-6-astra | 3% | — | held |
sample data, shown for layout
Incidents, then alerts
Provider failures become incident records — with reason, duration and attempt count — and the alert hook is driven by the same records.
Export targets
Structured logs and a webhook. OpenTelemetry/OTLP and Prometheus exporters are not implemented yet.
Credential rejected
A 401 retires the credential until an operator restores it; the incident stays open until then.
Rate limit or quota
The credential cools down for the configured window and rejoins selection automatically.
Recovery
Optional notification when a credential returns to rotation after a probe succeeds.
Delivery
Webhook delivery with retry and a per-provider minimum interval so one flapping account cannot flood the channel.
Next step
Talk to us about your architecture
Tell us how your traffic is shaped today. We will walk through where a forward path fits, what the failure policy should look like, and how the gateway would be deployed in your environment.
No pricing on this page. Every deployment is scoped individually.
- A review of your current provider and key layout
- A failure policy matched to your error classes
- A deployment shape for your network