Skip to content

Routing and reliabilityChecklist

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

Status pages update after your users notice. Half of the 429s in an incident are not rate limits. And the retry loop meant to help is often what keeps you down. A minute-by-minute runbook for an AI provider outage.

By INFRO Editorial

Published

5 min read

An amber signal line on a dark ground breaking at one node and rerouting smoothly through a second glass node, representing failover during an outage

In short

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.
On this page
  1. Minute 0–5: is it the provider, or is it you?
  2. Minute 5–10: stop making it worse
  3. Minute 10–20: fail over, or degrade
  4. Minute 20–30: communicate and watch
  5. After the incident
  6. How INFRO behaves in a provider outage
  7. Summary

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 Codex1, so check the API components, not the product most people talk about.

Then read the codes:

You seeOpenAI meaningAnthropic meaningRetry?
500Issue on OpenAI's serversapi_error, internalYes, with backoff
503 server_is_overloadedModel temporarily overloaded—Yes, honour Retry-After
529 overloaded_error—API temporarily overloadedYes, with backoff
504 timeout_error—Request timed out while processingOnce; consider streaming
429 rate limitRequests or tokens too fastRate limit exceededYes, after Retry-After
429 slow_downRequest rate rose too quicklyAcceleration limit (sharp increase)Yes, ramp up gradually
429 spend or usage limitOrganization or project spend limit, or org usage limitMonthly spend cap: enforced_spend_limit_reachedNo
429 exhausted balanceNo balance remains on the account—No
400 spend limit you set—"You have reached your specified API usage limits"No
401 / 403Invalid key, wrong org, IP not allowed, regionauthentication_error, permission_errorNo
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 code2. 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 resumes3. A spend limit you set yourself on Anthropic returns 400, not 4294. 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 limits24. 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 time5. Remember that SDKs retry by default; Anthropic's SDK retries transient failures twice4. 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 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 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 limits4.

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 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 readers ask

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.

From the team that builds it

Where this shows up in INFRO

INFRO is a control plane in front of the provider accounts you already hold. The capabilities below are the parts of it this article touches, each with the documentation that defines its behaviour.

INFRO accounts are self-serve. Provider usage is billed to you by your providers; INFRO charges a software subscription and takes 0% of model spend. See plans.

Sources

Numbered in order of first citation. Each was opened and checked against the claim on the date shown.

  1. 1.OpenAI Status (opens in a new tab) — OpenAI. Accessed Oct 20, 2026.
  2. 2.Error codes (opens in a new tab) — OpenAI. Accessed Oct 20, 2026.
  3. 3.Rate limits (opens in a new tab) — Anthropic. Accessed Oct 20, 2026.
  4. 4.Claude API errors (opens in a new tab) — Anthropic. Accessed Oct 20, 2026.
  5. 5.Rate limits (opens in a new tab) — OpenAI. Accessed Oct 20, 2026.

About this article

Error codes and retry guidance are taken from OpenAI's error codes and rate limit guides and Anthropic's errors and rate limit pages, opened on 2026-10-20. The runbook steps are general incident practice. Written by the team that builds INFRO.

Last checked against its sources on . The next review is due by . No separate named reviewer is recorded for this article.

How articles are written, sourced and corrected is set out in the editorial standards.

Read next