OpenRouter Is Down? How to Fail Over to a Backup Provider in 2 Minutes

If you are reading this because OpenRouter just started returning 5xx errors and your app went quiet, here is the short version: the fix is not waiting on a status page. It is multi-provider fallback, and you can wire it up in about two minutes.

This post explains why single-gateway outages happen, how to tell which layer is failing, and the exact config that routes around it the next time.

First, confirm what is down

When "OpenRouter is down," one of three things is usually true, and they need different responses:

1. The upstream provider is degraded. OpenRouter routes to OpenAI, Anthropic, Google, and dozens of others. If Anthropic is having an incident, every gateway in front of Anthropic feels it, OpenRouter included. Check the provider's own status page.
2. OpenRouter's routing layer is erroring or timing out. This shows up as 5xx responses or long stalls even when the underlying provider is healthy. Check status.openrouter.ai.
3. You are rate limited on a specific model. This returns 429s, not 5xx, and it is usually per-model or per-account. We cover this in depth in OpenRouter rate limits and how fallback fixes them.

The common thread across all three is a single point of failure. If your application only knows how to talk to one gateway on one provider path, any single incident anywhere in that chain becomes your outage.

Why a single gateway is a single point of failure

A gateway that gives you 300+ models through one endpoint is convenient right up to the moment that endpoint has a bad day. Convenience and resilience are not the same property. One API key and one base URL means one thing to break.

Resilience comes from having more than one path to a working model and switching between them without a human in the loop. That is failover, and it is the difference between a provider incident being a page in your on-call channel versus a page for your customers.

The 2-minute fix: a fallback policy across providers

The goal is simple. Define an ordered list of models across different providers. Send your request to the top of the list. If that path returns a 5xx or times out, retry the next one. Your users see a slightly slower response instead of an error.

With Requesty, you change one base URL and reference a fallback policy. Requesty is an OpenAI-compatible AI gateway over 596 models, so this is a drop-in change for anything already speaking the OpenAI SDK, OpenRouter included.

from openai import OpenAI
 
client = OpenAI(
    base_url="https://router.requesty.ai/v1",
    api_key="your-requesty-key"
)
 
# Reference a named fallback policy instead of a single model.
# Requesty tries each provider in order until one succeeds.
response = client.chat.completions.create(
    model="requesty/your-fallback-policy",
    messages=[{"role": "user", "content": "Summarize this ticket."}]
)

You define the policy once in the dashboard: a primary model, then one or two backups on different providers. For example, Claude on Anthropic as the primary, GPT-5 on OpenAI as the first backup, and an open-weight model on a third provider as the last resort. Because the backups sit on separate providers, a single provider incident cannot take all of them down at once.

For the mechanics of retries, backoff, and jitter that sit underneath this, see designing fallback, retries, and jitter.

What failover looks like when it works

• A provider returns a 5xx. Requesty retries the same provider a configured number of times with exponential backoff, then moves to the next model in the chain. Failover completes in under 50ms.
• A provider times out. The request cuts over to the backup path rather than hanging until your client gives up.
• A model is rate limited (429). The chain moves to a model on a different provider that is not rate limited, which is exactly the case we break down in the rate limits post.

None of this requires a redeploy. You edit the policy in the dashboard and every future request follows the new order.

Set it up before the next outage, not during

The best time to configure fallback is when nothing is broken. If you are mid-incident right now, the fastest path is:

1. Sign up at app.requesty.ai and create an API key.
2. Point your existing OpenAI-compatible client at https://router.requesty.ai/v1.
3. Create a fallback policy with two or three models on different providers.
4. Reference the policy name as your model and ship.

You keep the same code, the same SDK, and access to 596 models through one endpoint. The difference is that the next provider incident becomes a routing decision instead of downtime.

If you are weighing gateways specifically on reliability and price, we lay out the tradeoffs in Requesty vs OpenRouter and the wider best LLM routing platforms compared guide.