# OpenAI or Claude API down? A runbook for the first 30 minutes

URL: https://infro.io/blog/openai-claude-api-down-runbook
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-20
Last modified: 2026-10-20
Last reviewed: 2026-10-20 (next review due 2026-11-19)
Topic: Routing and reliability
Format: Checklist

> When an AI provider fails, first confirm it is the provider and not your own key, quota or spend limit, by reading the error code and body rather than the status page. Then stop retry storms with a circuit breaker, fail over to another provider or model that has been tested for the workload, move non-urgent work to a queue, and tell users what still works. Do not retry errors that need action: invalid keys, exhausted balances and spend caps (OpenAI's spend-limit 429s, Anthropic's enforced_spend_limit_reached) keep failing until someone fixes them.

Key takeaways:
- Read the error, not the status page: the code and body tell you whether it is the provider, your quota or your spend cap.
- Not every 429 is a rate limit. OpenAI's spend-limit and balance 429s and Anthropic's enforced_spend_limit_reached will not clear on retry.
- OpenAI's 503 server_is_overloaded and Anthropic's 529 overloaded_error are capacity problems: back off, honour Retry-After, fail over.
- Stop retry storms first. Failed attempts still count against rate limits, so blind retries extend the outage.
- Fail over only to targets you have tested for the workload, and degrade gracefully where you cannot.

**What should you do when the OpenAI or Claude API goes down?** First confirm it is the provider: read the error code and body from your own requests, because the status page updates after your users notice. Then stop retry storms, fail over to a provider or model you have already tested for the workload, queue anything that can wait, and tell users what still works. Do not retry errors that need a human — invalid keys, exhausted balances and spend caps fail until someone acts.

Keep this page open in the incident. Each step lists what to check and what to change.

## Minute 0–5: is it the provider, or is it you?

The fastest signal is your own error rate by status code, per provider and model. Status pages such as status.openai.com list components separately for the API, ChatGPT and Codex[1], so check the API components, not the product most people talk about.

Then read the codes:

| You see | OpenAI meaning | Anthropic meaning | Retry? |
| --- | --- | --- | --- |
| 500 | Issue on OpenAI's servers | `api_error`, internal | Yes, with backoff |
| 503 `server_is_overloaded` | Model temporarily overloaded | — | Yes, honour `Retry-After` |
| 529 `overloaded_error` | — | API temporarily overloaded | Yes, with backoff |
| 504 `timeout_error` | — | Request timed out while processing | Once; consider streaming |
| 429 rate limit | Requests or tokens too fast | Rate limit exceeded | Yes, after `Retry-After` |
| 429 `slow_down` | Request rate rose too quickly | Acceleration limit (sharp increase) | Yes, ramp up gradually |
| 429 spend or usage limit | Organization or project spend limit, or org usage limit | Monthly spend cap: `enforced_spend_limit_reached` | **No** |
| 429 exhausted balance | No balance remains on the account | — | **No** |
| 400 spend limit you set | — | "You have reached your specified API usage limits" | **No** |
| 401 / 403 | Invalid key, wrong org, IP not allowed, region | `authentication_error`, `permission_error` | **No** |

Table: From OpenAI's error codes guide and Anthropic's errors and rate limit pages, 2026-10-20.

Two rows cause most misdiagnoses:

- **A 429 that is not a rate limit.** OpenAI returns 429 for an organization or project spend limit, an organization usage limit and an exhausted balance, each with its own code[2]. Anthropic returns 429 when an organization reaches its tier's monthly spend cap, with `error.details.error_code` set to `enforced_spend_limit_reached` and **no** `retry-after` header; retrying, including the SDK's automatic retries, fails until access resumes[3]. A spend limit you set yourself on Anthropic returns 400, not 429[4]. If your dashboards group every 429 as "rate limited", you will spend the incident tuning backoff for a problem that needs a billing change.
- **A sharp traffic increase.** Both providers can refuse a sudden ramp: OpenAI's `slow_down` and Anthropic's acceleration limits[2][4]. A deploy that doubled traffic can look exactly like an outage.

## Minute 5–10: stop making it worse

- **Cap retries now.** OpenAI notes that failed attempts count toward your per-minute limit, so rapid resending makes things worse; treat `Retry-After` as a minimum, add jitter, and cap both the number of attempts and the total retry time[5]. Remember that SDKs retry by default; Anthropic's SDK retries transient failures twice[4]. Three layers of retries during an overload is a self-inflicted outage.
- **Open the circuit.** If a provider's error rate is above your threshold, stop sending it traffic for a short interval instead of letting every request discover the failure. [Circuit breakers for LLM providers](https://infro.io/blog/llm-circuit-breakers-throttling) explains why throttling should not trip the same breaker as failure.
- **Pause background jobs.** Batch backfills, evaluation runs and re-indexing compete with user traffic for the same limits. Stop them first.

## Minute 10–20: fail over, or degrade

Failover is only safe to a target you have tested **for this workload**: prompts tuned for one model can behave differently on another, and structured output, tool calling and context limits differ.

Choose, per feature:

1. **Same model, another provider.** Claude on the Claude API and on Google Cloud; GPT models on OpenAI and Azure OpenAI. The behaviour is closest; the provider account and quota are separate.
2. **Another model, tested.** A fallback model that has passed your evaluation for this task.
3. **Degrade.** Show cached or partial results, switch the feature to a simpler mode, or queue the request and notify the user when it completes.
4. **Fail clearly.** If none of the above is acceptable, tell the user the AI feature is unavailable and that the rest of the product works.

Streaming adds a rule: once a response has started reaching the user, a failure ends that response. Retrying silently would show the user two different beginnings. Fail over before the first byte, and let a broken stream end with a clear message. [Streaming LLM failures](https://infro.io/blog/streaming-llm-failure-modes) covers recovery.

## Minute 20–30: communicate and watch

- **Tell users what works.** "Summaries are delayed; everything else is normal" is better than a generic error.
- **Watch cost as well as errors.** Failover to a larger model, or a retry storm on a provider that bills failed-but-started requests, can make an outage expensive. Check spend per minute alongside error rate.
- **Plan the return.** When the provider recovers, ramp traffic back gradually; a sudden return of full traffic can trip acceleration limits[4].

## After the incident

- Record which errors you saw, per provider, model and minute, and how long until you noticed.
- Note which fallbacks were used and whether quality held.
- Turn the decisions you made by hand into configuration: failure rules, breaker thresholds, fallback chains.
- Schedule a [failover drill](https://infro.io/blog/llm-failover-drills) so the next switch is rehearsed rather than improvised.

## How INFRO behaves in a provider outage

INFRO routes over provider accounts you connected. On a route, each kind of upstream failure has its own rule — `rate_limit`, `server_error`, `timeout`, `connection`, `credential`, `moderation` — set to retry on the same target, fail over to the next target at once, or stop. Failover happens before any bytes reach your client, and once a stream has started INFRO will not silently restart it. Every attempt is on the request's trace with the connection that made it and the error that ended it, so the post-incident timeline is already written. INFRO holds no provider capacity of its own, so failover moves only between your own connections; if none of them can serve the request, it fails with an error naming each attempt.

## Summary

Read the codes before the status page, separate rate limits from spend caps, stop retry storms, fail over only to tested targets, degrade where you cannot, and make each manual decision from the incident into configuration before the next one.

## Questions

### How do I know if the OpenAI API is down or it's my account?

Read the error code and message. A 503 with server_is_overloaded or a 500 points at OpenAI. A 401 points at your key, and a 429 can be a rate limit, a spend limit you set, an organization usage limit or an exhausted balance; the message says which. Check status.openai.com as well, but your own error rate usually moves first.

### What does Claude's 529 overloaded_error mean?

Anthropic's errors page describes 529 overloaded_error as the API being temporarily overloaded, which can happen under high traffic across all users. Back off, honour any retry-after header, and fail over to another Claude provider or a tested fallback model if it persists.

### Should I retry when the LLM API returns 429?

Only if it is a rate limit. Wait at least the Retry-After value with jitter, and cap attempts and total time. Do not retry spend-cap or balance 429s: Anthropic's monthly spend cap 429 has no retry-after header and keeps failing until access resumes.

## Sources

1. OpenAI Status — OpenAI. https://status.openai.com/ (accessed 2026-10-20)
2. Error codes — OpenAI. https://developers.openai.com/api/docs/guides/error-codes (accessed 2026-10-20)
3. Rate limits — Anthropic. https://platform.claude.com/docs/en/api/rate-limits (accessed 2026-10-20)
4. Claude API errors — Anthropic. https://platform.claude.com/docs/en/api/errors (accessed 2026-10-20)
5. Rate limits — OpenAI. https://developers.openai.com/api/docs/guides/rate-limits (accessed 2026-10-20)