Observatory

What the Observatory measures

The Observatory tracks whether the 71 chat models routable through BlockRun are actually answering, and how quickly. Each model is exercised with real completion requests rather than a status endpoint or a health-check ping. That distinction matters: a provider can return a healthy 200 from its status page while the model behind it is timing out, returning empty completions, or silently falling back to a different model. Only a real request catches that.

Latency and uptime

Latency is measured end to end, from the moment the gateway dispatches a request to the moment a usable response is complete — so it includes the upstream provider's queueing and inference time, not just network transit. Uptime is the share of probes that returned a valid completion over the window shown. A model that responds slowly is reported as slow rather than down; a model that returns an error, an empty body, or nothing at all inside the timeout is counted as a failure.

How this affects your requests

These measurements are not only for display. When a model degrades, the gateway can route around it, and free-tier models that stop answering are pulled from the rotation automatically until they recover. Because BlockRun charges per successful call, a failed request is not billed — you are not paying for an outage. If a model you depend on is showing degraded numbers here, the practical response is usually to switch the model field to a comparable alternative from the catalog, which is a one-line change.

Scope and caveats

Numbers here describe models as reached through BlockRun. They are a fair signal for what you should expect calling through this gateway, but they are not a verdict on a provider's own service: a regional outage, a rate limit applied to our traffic, or a transient network fault between us and an upstream will show up as degradation here without necessarily affecting a direct integration. Probes run continuously, and the window shown is rolling rather than a daily snapshot.