OpenRouter down? How to fail over in 2 minutes (2026)

Updated August 14, 2026. Status signals, error codes and endpoints verified at publish time.

OpenRouter is, at the time of writing, fine: its status page shows all systems operational and no incidents in the last 14 days. That makes right now exactly the moment to set up a failover path, because the middle of an incident is the worst possible time to be reading documentation, creating accounts and rotating keys. This guide is the calm version of the outage playbook, and it is written to be useful even if you never leave OpenRouter: how to tell what is actually broken, how to swap to a second OpenAI-compatible path in about two minutes, and how to make the next incident a non-event no matter which gateway serves your traffic day to day.

How do the two failover paths compare?

Both OpenRouter and Opper's gateway speak the OpenAI protocol, which is what makes a two-minute switch realistic in the first place. The mechanics side by side:

Is OpenRouter down, or is your model's provider down?

Before switching anything, spend one minute finding out where the failure actually lives, because the fix differs. Start at the official status page, which monitors the chat API, the data API, the homepage and auth as separate components and keeps its incident history public. Read it with normal skepticism in both directions, since status pages can lag reality or overreport it, and OpenRouter's most recent listed incident, a brief outage report on the chat API from July 23, 2026, is one they later marked as posted in error. If the status page is green but your requests are failing, the error code is your best signal, and OpenRouter documents these precisely in its error reference: a 502 means "your chosen model is down or we received an invalid response from it", a 503 means "there is no available model provider that meets your routing requirements", and a 429 is a rate limit, where OpenRouter may include a Retry-After header that is worth honoring before you retry.

A 502 or 503 usually points upstream rather than at OpenRouter itself. OpenRouter model pages have an uptime tab, at openrouter.ai/{model-slug}/uptime, showing per-provider availability for that model, and their uptime guide explains the monitoring behind those charts. Cross-check the provider's own status page too, status.openai.com or status.anthropic.com for example, and if you want an independent read on OpenRouter itself, third-party monitors like IsDown and StatusGator track it from the outside.

How do I fail over from OpenRouter in two minutes?

Because both gateways are OpenAI-compatible, the entire switch is a base URL and an API key. With an Opper key in hand, point the same SDK at the compat endpoint:

import os
from openai import OpenAI

client = OpenAI(
  base_url="https://api.opper.ai/v3/compat",  # was https://openrouter.ai/api/v1
  api_key=os.environ["OPPER_API_KEY"],
)

response = client.chat.completions.create(
  model="openai/gpt-5-mini",
  messages=[{"role": "user", "content": "Hello"}],
)

Model ids in the provider/model format generally carry over, openai/gpt-5-mini works as-is, and you can confirm the exact id for anything else in the model directory, which lists 700+ models, with client.models.list() on the same base URL, or via the public GET https://api.opper.ai/v3/models endpoint. Streaming works through the standard stream parameter. If your application already builds its client from the environment, the OpenAI SDK reads OPENAI_BASE_URL and OPENAI_API_KEY out of the box, so the failover needs no code change at all:

export OPENAI_BASE_URL="https://api.opper.ai/v3/compat"
export OPENAI_API_KEY="$OPPER_API_KEY"
# restart the service, done

That is the whole emergency procedure, and it is symmetric: switching back when the incident clears is the same two lines in reverse. If the standby path ever turns into a full migration, the OpenRouter alternative page covers that longer comparison properly.

Doesn't OpenRouter already fail over automatically?

Yes, and credit where due, its in-platform story is genuinely good. By default OpenRouter load-balances across providers and prioritizes ones that have not seen significant outages in the last 30 seconds, fallback providers are tried in order automatically with allow_fallbacks on by default, an order array pins provider priority, and a models array adds model-level fallback on top. For upstream provider incidents, the most common failure mode, that machinery does its job, and OpenRouter's own writing on reliability explains the design well.

What no gateway's internal failover can cover is an incident in the routing layer itself, a limitation OpenRouter's reliability write-up openly acknowledges. When the path your requests travel through is the thing that is degraded, fallback settings inside that same path do not help, which is why teams that care about availability keep a second, independent OpenAI-compatible route warm. This is not a judgment about any vendor, it is just topology: resilience to a single point of failure requires a second point.

What's the permanent fix so the next outage is a non-event?

Swapping a base URL during an incident works, but the better end state is failover that happens per request inside the gateway, so nobody is editing environment variables at 2 a.m. On Opper there are two mechanisms for this. The first is plain model names: call claude-haiku-4-5 instead of pinning one provider/model route, and the gateway sends each request to a healthy provider currently serving that model, falling through to the next deployment if one fails. We described the mechanism in one model name, every provider. The second is aliases, a stable name you define on the platform that maps to an ordered list of models, a primary plus fallbacks, and the gateway tries each in order if one is unavailable or errors, a pattern we first wrote up in aliases and fallback.

How much this buys you is measurable rather than rhetorical, and the /uptime page publishes the numbers live: for each model it tracks, it shows 30-day availability of the model through any healthy route next to the average of its single routes, measured via StatusGator and refreshed hourly. As of August 2026 the gap is the whole argument in one line, Claude Opus 5 sits at 100% any-route availability while its four measured routes averaged 95.71% on their own, and Claude Fable 5 shows 100% against a 94.28% single-route average across three routes. The gap is not uniform either, DeepSeek V4 Pro's five routes averaged 99.73% over the same window, so multi-route redundancy buys the most for the models whose individual routes had the roughest month, which is exactly what a per-model table lets you check before you depend on one. Any single deployment has bad days, the set of them together very rarely does.

OpenRouter down FAQ

Set up the standby before you need it

The two-minute fix only takes two minutes if the account and key already exist, so the practical takeaway is to create the standby now, while everything is green. Create a free account, grab a key, send one test request against https://api.opper.ai/v3/compat, and keep the env swap in your incident runbook. The model directory has the exact ids, and /uptime shows, live and per model, what multi-provider failover buys you on the days when a single route has a bad one.