OpenRouter Status: How to Check If the OpenRouter API Is Down Right Now (2026)
Updated July 2026 · 6 min read · API Status Check
Quick Answer
Check OpenRouter status at status.openrouter.ai (official) for real-time platform status. You can also test the API directly at openrouter.ai/api/v1/chat/completions.
📡 Monitor your APIs — know when they go down before your users do
Better Stack checks uptime every 30 seconds with instant Slack, email & SMS alerts. Free tier available.
Affiliate link — we may earn a commission at no extra cost to you
The Official OpenRouter Status Page
OpenRouter maintains an official status page at status.openrouter.ai. It tracks status across the OpenRouter platform:
What Each OpenRouter Status Means
Monitor OpenRouter API health independently
Better Stack monitors OpenRouter endpoints from multiple global locations — so you get alerted the moment routing degrades, before it breaks your production app. Free tier included.
Try Better Stack Free →OpenRouter API for Production: Resilience Patterns
OpenRouter's whole value proposition is abstracting away single-provider risk — but that only works if your integration actually uses the fallback features. Here is how to stay resilient against OpenRouter and upstream-provider outages:
Configure Provider-Level Fallbacks in the Request
OpenRouter supports a `models` array and provider routing preferences so a single request can fail over to an alternate model or provider automatically if the primary is unavailable, instead of returning an error to your app.
# Example request body with fallback models
{
"models": ["anthropic/claude-sonnet-4.6", "openai/gpt-5", "google/gemini-2.5-pro"],
"route": "fallback",
"messages": [{"role": "user", "content": "hi"}]
}Implement Exponential Backoff for API Calls
OpenRouter errors during upstream capacity pressure are usually transient. Use exponential backoff with jitter: 1-second initial delay, double each retry, ±20% jitter, up to 60 seconds.
# Python retry pattern for OpenRouter
import time, random
def openrouter_with_retry(fn, max_retries=4):
for attempt in range(max_retries):
try:
return fn()
except Exception as e:
if attempt == max_retries - 1:
raise
delay = (2 ** attempt) + random.uniform(0, 1)
time.sleep(min(delay, 60))
continueWatch Per-Model Status, Not Just the Platform
A model can be unavailable while OpenRouter itself is fully operational, because the upstream provider hosting that model is degraded. Check the model's provider column on openrouter.ai/models before assuming OpenRouter is broken.
Track Credit Balance Separately From Outages
A depleted credit balance produces errors that look like an outage but are not. Keep a low-balance alert in your billing dashboard so you can rule this out before troubleshooting a false "outage."
5 Ways to Check OpenRouter Status Right Now
Official OpenRouter Status Page
Visit status.openrouter.ai for real-time component status covering the API, routing layer, and website.
status.openrouter.ai →Test the OpenRouter API Directly
Make a quick chat completions call to verify the endpoint is responding:
# Quick OpenRouter API health check
curl -s -o /dev/null -w "%{http_code} — %{time_total}s\n" \
-X POST https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"openai/gpt-5-mini","messages":[{"role":"user","content":"hi"}],"max_tokens":1}'
# 200 = healthy, 429 = rate limited/low credit, 503 = outageCheck the OpenRouter Dashboard
Log into openrouter.ai and review your activity and error-rate views. A spike in errors often shows in your dashboard before an incident is posted publicly.
OpenRouter Activity →Search X/Twitter
Search 'OpenRouter down' or 'OpenRouter outage' on X. OpenRouter's developer community reports issues quickly.
Search X for 'openrouter down' →Check the Specific Model’s Provider
If only one model fails, check openrouter.ai/models for that model's upstream provider status. If the fallback route works but the primary model fails, the issue is upstream-provider-specific, not OpenRouter.
Common OpenRouter API Errors During Outages
These are the errors and symptoms you'll encounter when OpenRouter or an upstream provider is having issues:
"HTTP 503 Service Unavailable from openrouter.ai"OpenRouter or the routed upstream provider is temporarily overloaded or down. Check status.openrouter.ai. 503s are often transient — retry with exponential backoff."HTTP 429 Too Many Requests"You hit a rate limit tied to your credit balance or the upstream provider’s limits. Implement backoff, check your balance, and consider adding credit or upgrading your usage tier."No available providers for model"Every upstream provider hosting the requested model is currently unavailable or rate-limited. Not necessarily an OpenRouter outage — add fallback models to your request to avoid hard failures."Request timeout / stream stalls mid-generation"Inference is timing out under heavy load at the upstream provider. Set explicit client timeouts and add retry logic with a fallback model."HTTP 500 Internal Server Error"An unexpected error on OpenRouter's infrastructure, usually transient. Retry with backoff; if 500s persist with no incident posted, check status.openrouter.ai and OpenRouter's Discord/X for reports."HTTP 401 Invalid API Key"Not an outage — your API key is missing, malformed, or revoked. Verify the key in your OpenRouter dashboard and confirm your Authorization header uses the Bearer scheme.What to Do When OpenRouter Is Down
Immediate Response
- Verify on status.openrouter.ai before troubleshooting your code
- Check whether it's platform-wide or a single model/provider
- Switch to a fallback model or direct provider API temporarily
- Pause batch jobs and back off retries to avoid 429 storms
- Surface a graceful error: "AI features temporarily unavailable"
Long-Term Resilience
- Always set a `models` fallback array instead of a single hardcoded model
- Keep a low-credit-balance alert separate from outage monitoring
- Monitor your own OpenRouter error rate — it detects degradation before status.openrouter.ai
- Test your fallback routing periodically — an untested fallback is useless
- Track which upstream providers you depend on most for concentration risk
Frequently Asked Questions
Where is the official OpenRouter status page?
OpenRouter's official status page is at status.openrouter.ai. It tracks the chat completions API, the model routing layer, and the OpenRouter website/dashboard.
Why does OpenRouter show one model down but not others?
OpenRouter routes to 300+ models across dozens of upstream providers. A single model going down usually means the specific upstream provider hosting that model is degraded — not that OpenRouter itself is having an outage. Check the model's provider on openrouter.ai/models.
Is OpenRouter downtime the same as running out of credits?
No. Running out of credits produces 402/429-style errors regardless of platform health — not an outage. An actual outage returns 500/503 errors or times out even with a healthy balance. Check your balance in the dashboard before assuming an outage.
How does OpenRouter compare to calling providers directly for reliability?
Calling a provider directly ties you to that provider’s uptime. OpenRouter adds a routing layer that can fail over between providers for the same model, which can improve effective reliability — but only if your request includes fallback models, since OpenRouter itself is a single additional dependency.
Does OpenRouter have an uptime SLA?
OpenRouter does not publish a standard uptime SLA for pay-as-you-go usage. For workloads needing guaranteed availability, pair OpenRouter with direct fallback calls to a provider API as a second layer of resilience.
Alert Pro
14-day free trialStop checking — get alerted instantly
Next time OpenRouter goes down, you'll know in under 60 seconds — not when your users start complaining.
- Email alerts for OpenRouter + 9 more APIs
- $0 due today for trial
- Cancel anytime — $9/mo after trial