Reliability and RoutingOctober 13, 2026Flatkey Team

OpenRouter Down? How to Fail Over Without Changing Code

Check whether OpenRouter is down, separate provider errors from platform incidents, and fail over with base_url, retries, provider fallback, and model fallback.

When people search OpenRouter Down, they usually need two answers fast: is OpenRouter actually down, and how do I keep requests moving without rewriting my app?

The safest answer is not to panic-switch models in code. First confirm whether the issue is OpenRouter-wide, provider-specific, account-specific, or your own retry queue. Then move failover into configuration: status checks, retry budgets, provider fallback, model fallback, and a swappable OpenAI-compatible base_url.

Checked date: October 13, 2026. Do not treat this article as proof that OpenRouter is down right now. Check the OpenRouter status page and your own logs before starting an incident.

The Short Answer

If OpenRouter is down, or if one OpenRouter route is failing, use this order:

Check https://status.openrouter.ai/ and your error logs.
Separate OpenRouter platform errors from upstream model/provider errors.
Honor Retry-After on 429, 503, and in-flight-budget 402 responses.
Keep provider.allow_fallbacks enabled unless a compliance rule requires otherwise.
Add model fallbacks through request configuration where the response quality contract allows it.
Put your API gateway or backup endpoint behind an environment variable so you can switch base_url without editing application code.

That last point is the real "without changing code" move. Your application should read the endpoint from configuration:

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

During an incident, your operations change becomes:

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

Your SDK code remains the same.

Is OpenRouter Down?

Do not infer OpenRouter Down from one failed request. A failed request can mean:

Symptom	Likely scope	What to check first
Status page incident	OpenRouter platform	Status page, incident timeline, public updates
`502 Bad Gateway`	Chosen model/provider may be down	Model, provider metadata, fallback eligibility
`503 Service Unavailable`	No provider meets your routing rules	Provider constraints, `only`, ZDR, parameter requirements
`429 Too Many Requests`	Rate limit or provider capacity	`Retry-After`, queue concurrency, provider fallback
`402 Payment Required`	Credits or in-flight spending budget	`Retry-After`, account balance, key limits
`403 Forbidden`	Budget, permissions, moderation, guardrail	`error.metadata`, workspace/key policy
Streaming starts, then error event appears	Provider failed after HTTP `200`	Inspect SSE body, not only initial HTTP status

OpenRouter's error docs state that 502 can mean the chosen model is down or returned an invalid response, while 503 can mean no available model provider meets the routing requirements. The same docs say OpenRouter may return Retry-After on 429, 503, and some in-flight-budget 402 responses. Source: OpenRouter errors and debugging.

OpenRouter has had public outages before. Its February 17 and 19, 2026 postmortem describes API failures from a third-party caching dependency and notes that some users saw confusing 401 errors during the incident. That historical post is useful context, but it is not evidence of a current outage. Source: OpenRouter outage postmortem.

First Five Minutes: OpenRouter Down Triage

Use this checklist before switching traffic.

Minute	Action	Decision
0-1	Check the OpenRouter status page and your alert timeline.	If the status page confirms an incident, move to failover readiness.
1-2	Group errors by status code, model, provider, route, and SDK.	If one model/provider is failing, avoid platform-wide assumptions.
2-3	Check `Retry-After`, retry count, and queue concurrency.	Stop retry storms before adding more fallback traffic.
3-4	Compare paid, free, batch, and agent workloads.	Preserve interactive traffic before background jobs.
4-5	Choose the smallest failover action that restores user-facing work.	Prefer provider fallback before cross-model fallback; prefer config switch before code deployment.

The main mistake during an OpenRouter Down incident is making every worker retry immediately. A retry storm can turn one provider error into a platform-wide queue problem inside your own app.

Failover Without Changing Code

The no-code-change pattern is simple: keep SDK usage stable and make the route configurable.

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

Then keep endpoint selection in environment, deployment config, feature flags, or your secret manager:

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

This works because OpenRouter's quickstart says its API can be used through the OpenAI SDK by pointing the SDK at OpenRouter. The same integration shape is exactly what makes a backup OpenAI-compatible gateway practical. Source: OpenRouter quickstart.

Use Provider Fallback Before Changing Models

If OpenRouter is reachable but one provider is struggling, provider fallback is the lowest-risk move. You keep the same model contract and let routing try another eligible provider.

OpenRouter's provider routing docs say requests are load balanced across top providers by default to maximize uptime, and the provider object includes allow_fallbacks, defaulting to true. The docs also warn that setting sort or order changes load-balancing behavior, and hard provider filters can reduce routing room. Source: OpenRouter provider routing.

Start with this:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

Be careful with this during an incident:

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

Strict routing may be correct for compliance, data-retention, region, or pricing policy. But strict routing is not a reliability setting. If you need strict routing for sensitive workloads, create a separate non-sensitive path that can fail over more freely.

Add Model Fallback Only When Outputs Are Interchangeable

Model fallback is stronger than provider fallback. It can keep the app alive when the primary model is down, rate-limited, or blocked, but it can also change output style, latency, cost, context length, tool behavior, and evaluation results.

OpenRouter's model fallback docs say the models parameter lets you provide model IDs in priority order. If the first model returns an error, OpenRouter tries the next model. The docs list rate limiting and downtime among the errors that can trigger fallback. Source: OpenRouter model fallbacks.

Use model fallback for tasks with a loose equivalence contract:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Summarize this support thread." }]
}

Avoid silent model fallback for tasks where the exact model is part of the product guarantee:

Workload	Model fallback stance
Internal summarization	Usually safe with evaluation and logging
Coding agent planning	Possible, but test tool-call behavior and instruction following
Structured extraction	Only if schemas and validation pass
Customer-visible creative copy	Possible, but expect style differences
Regulated or contractual output	Do not silently change models
Benchmarking or evals	Do not fallback unless the fallback is the test subject

A Practical Incident Policy

This policy is intentionally boring. It keeps OpenRouter Down response work operational rather than dramatic.

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

The key fields to log are:

Field	Why it matters
`base_url`	Proves which gateway handled the request
`requested_model`	Shows the caller's intended model
`served_model`	Shows the model actually used after fallback
`provider`	Separates platform problems from provider problems
`status_code`	Drives retry/failover decisions
`retry_after`	Prevents retry storms
`attempt`	Shows whether retries are amplifying traffic
`fallback_reason`	Makes incident review possible
`cost`	Confirms fallback did not create a surprise spend spike
`request_id`	Lets support and engineering trace one request

Where Flatkey Fits

Flatkey is useful when you want the OpenRouter Down playbook to live outside application code. The project positioning for Flatkey is a unified LLM API gateway: one key, one balance, and an OpenAI-compatible endpoint for routing across official text, image, and video models. In this incident pattern, the practical value is operational:

Keep your app on an OpenAI-compatible client shape.
Route a workload through a backup base_url without changing app logic.
Centralize model allowlists, sub-keys, request logs, budget controls, and fallback policy.
Compare gateway behavior using request evidence rather than anecdotes.

Do not move every workload during a small incident. Move one representative workload first, watch error rate, latency, selected model, fallback reason, and cost, then decide whether to widen the switch.

Useful next reads:

OpenRouter Down FAQ

Is OpenRouter down right now?

Check the OpenRouter status page first. This article explains how to respond when OpenRouter Down searches map to a real incident or a local provider failure; it does not assert that OpenRouter is down right now.

What should I do first if OpenRouter is down?

Pause aggressive retries, inspect status codes, and preserve interactive traffic. If the incident is confirmed, prefer provider fallback before model fallback, and prefer a base_url configuration switch before a code deployment.

Can I fail over from OpenRouter without changing code?

Yes, if your app already reads the OpenAI-compatible endpoint from configuration. Put baseURL or base_url behind an environment variable, keep the SDK call shape stable, and switch the endpoint in deployment config.

Should I use OpenRouter model fallbacks during an outage?

Use model fallbacks only when the fallback model is acceptable for the task. They are appropriate for many internal workflows, but not for evals, regulated outputs, or cases where customers were promised a specific model.

What is the safest long-term fix for OpenRouter Down risk?

Design for route-level portability: configurable base_url, request-level logging, retry budgets, provider fallback, tested model fallback contracts, and a backup OpenAI-compatible gateway path. The goal is not to avoid every outage; it is to make the failover boring.