OpenRouter status

How we check OpenRouter

We watch openrouter.ai/api/v1/models from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

The models endpoint answers an anonymous request with the current catalogue, so it can be checked honestly without a key, and it exercises the routing layer rather than the marketing site. It deliberately does not measure the upstream providers OpenRouter forwards to, whose own outages are the more common cause of a failed completion.

What is OpenRouter?

OpenRouter is an aggregator for language models. Rather than integrating separately with each provider, an application sends a request to one API naming a model, and OpenRouter forwards it to a provider that serves it, handling authentication, billing, and fallback along the way. The appeal is obvious for anyone who has maintained several provider integrations at once, and it introduces a dependency structure worth understanding before something fails.

The structure is that there are two layers, and either can be the problem. OpenRouter's own routing layer is one. The upstream providers actually running the models are the other, and they are numerous, independently operated, and have their own incidents. A failed completion can mean OpenRouter is unavailable, or that the provider selected for that request is having a bad hour while OpenRouter is entirely healthy. Because the error surfaces through the same API in both cases, a single status indicator, ours included, cannot tell you which. The response metadata naming the provider is what actually resolves it.

This is also where the aggregator earns its keep. When a model is offered by several providers, routing can move traffic away from one that is failing, which turns an upstream outage into a latency change rather than an error. That behaviour depends on the routing preferences configured for the request, and applications that pin a single provider for consistency have deliberately traded that resilience away. Both choices are reasonable; what causes trouble is not knowing which one is in effect.

Variability is the day-to-day consequence. The same model can be served by different providers on different requests, with different hardware, different load, and therefore different response times. An application built around a predictable latency profile will find that surprising, and the answer is either to pin the provider or to measure per provider rather than per model.

The last point is about attribution during an incident. When a model-backed feature stops working, the chain now has at least three links: your application, OpenRouter, and whichever provider served the request. Logging the provider and the model with every request costs nothing and is the difference between diagnosing that chain in minutes and guessing at it for an afternoon.

Frequently asked questions

Is OpenRouter down right now?

Check the board above; it reflects our own probes against OpenRouter's API from all five of our regions, refreshed every couple of minutes. This measures OpenRouter's own routing layer, not the model providers it forwards requests to.

My request failed but OpenRouter looks up. Which provider is the problem?

Check which upstream provider served the request, because OpenRouter is a router and a failure can belong to the model provider rather than to OpenRouter. The response metadata names the provider that handled it, and a model available through several providers can be failing on one and healthy on another. That distinction is invisible if you only look at a single status page.

Why did the same model give me different latency on different requests?

Because requests for one model can be served by different upstream providers with different hardware and load. That variability is the trade for the routing convenience, and it is why an application sensitive to latency should either pin a provider or measure the outcome per provider rather than assuming a model behaves consistently.

What happens when a provider is down but the model is available elsewhere?

Routing can send the request to another provider offering the same model, which is one of the reasons to use an aggregator at all. Whether that happens depends on your routing preferences, so a configuration that pins a single provider gives up the fallback in exchange for consistency. It is worth knowing which of those two you chose before an incident rather than after.

Does an OpenRouter outage affect my credits or usage records?

Usage is recorded per request, so an incident affects your ability to make requests rather than the accounting for ones already made. After any incident it is still worth reconciling your own request log against the activity view, particularly if your application retried aggressively, since retries that succeeded are real requests that were billed.