# OpenRouter status

> Is OpenRouter down? Live status for the OpenRouter API, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-08-31 | Canonical: https://yoping.me/status/openrouter

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/openrouter. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.