How to read FlyRouter service metrics
The status page reports observations from gateway requests over the displayed window. Observed success rate, response latency and contractual availability are different measures; this guide explains what the public data can and cannot establish.
Updated:
What the public page shows
| Metric | Interpretation |
|---|---|
| Success rate | The success percentage reported by the gateway for the displayed window |
| Time to first token | Time until the first token for requests that report that measurement |
| Response latency | Request duration; it must not be presented as time to first token |
| Per-model timeline | Hourly observations; gaps mean no observation, not a guaranteed outage or success |
The initial page can contain a server-fetched snapshot. The status page refreshes periodically in the browser. A page refresh is not a guarantee that a new model probe has run. Missing or invalid measurements remain unavailable; targets are not substituted for observations.
Limits of the current summary
The public summary does not provide all the information needed for an independent performance benchmark. Without request counts, traffic mix, region and percentile measurements, a single average or percentage cannot establish how the service will perform for your workload. Do not interpret a displayed 100% as a guarantee of future success.
No traffic is different from an outage. A gateway error is also different from a model answer that is factually wrong or fails your task. Evaluate task quality separately.
Availability versus SLA
Historical observations are not a contractual service-level agreement. The service terms explain the current commitment; contact support if you need a separate written agreement. Upstream availability can affect requests. The gateway's published routing policy is to return upstream errors without silently substituting a different model.
What a reproducible report should include
Before publishing a benchmark, collect the model and route, date and region, sample size, concurrency, streaming setting, input and output lengths, retries, error categories and measurement definitions. Report P50 and P95 only when request-level measurements exist. Include unsuccessful attempts and avoid dropping slow requests from the sample.
See service status, error handling and cost reconciliation.