ChatGPT Went Down for 50 Minutes. Build the Second Lane This Afternoon

ChatGPT, Codex and the OpenAI API went down worldwide this morning: roughly 50 minutes from about 5:00 AM ET, with a status acknowledgment at 5:30 and full recovery by 6:00, according to BleepingComputer. If your product calls exactly one model API and has no second lane, your users spent that window looking at a spinner or a stack trace. The fix is not an architecture project. It is six steps you can finish in an afternoon, and the first one is arithmetic, not code.

Step 1: Convert the published uptime into hours

Both major providers publish availability, and the numbers are not secret. OpenAI's status page showed, for April to July 2026, APIs at 99.93% across 12 components and ChatGPT at 99.67% across 15. Claude's status page showed 90-day figures of 99.54% for the API, 99.42% for claude.ai and 99.46% for Claude Code. All checked July 25, 2026.

Percentages hide the thing you actually plan against. This conversion is ours: multiply the missing fraction by the hours in the window.

Two caveats that matter before you quote these at anyone. Both pages aggregate: OpenAI states plainly that "availability metrics are reported at an aggregate level across all tiers, models and error types," so a specific model on a specific tier can be worse than the headline. And the windows differ, so the columns are not a like-for-like ranking of vendors. The point is the order of magnitude. Planning on the assumption that a model API is always up is planning against a number that is visibly not 100%.

Step 2: Stop catching every exception the same way

Most single-provider integrations wrap the call in one broad try/except and treat everything as failure. The vendors document their codes precisely, so you can be precise back. From OpenAI's error codes: 429 for "Rate limit reached for requests" or an exceeded quota, 500 for "The server had an error while processing your request", 503 for "The engine is currently overloaded, please try again later", plus a distinct "Slow Down" error. From the Claude API errors page: 429 rate_limit_error, 500 api_error, 504 timeout_error and 529 overloaded_error, which the docs say "can occur when the API experiences high traffic across all users."

That gives you three behaviours instead of one:

• Never retry: 400 invalid request, 401 auth, 402 billing, 403 permission, 404 not found, 413 request too large. Retrying a bad API key 5 times is 5 failures, not resilience.
• Back off and respect the header: 429. Both vendors say the same thing here. Anthropic additionally warns that a sharp usage increase can trip acceleration limits, so ramp traffic gradually rather than stepping it.
• Retry, then fail over: 500, 503, 504, 529. These are the provider's problem, and they are exactly the codes a second lane exists for.

One special case worth handling by name: OpenAI's "Slow Down" response asks you to reduce your rate, hold it stable for 15 minutes or more, then increase gradually. A naive exponential-backoff loop that only counts failures will not do that.

Step 3: Use the SDK's retry logic instead of writing your own

Anthropic's official SDKs "automatically retry transient failures (such as connection errors, rate limits, and 5xx server errors) with exponential backoff, twice by default, honoring the retry-after header when present," and every client accepts a max-retries option. That is better than most hand-rolled loops, and it is already installed. Set the retry count deliberately, set a request timeout, and log the request-id header that comes back on every response so a support ticket takes one message instead of three.

Step 4: Add the second lane

There are two credible routes, and they trade the same thing in opposite directions.

Managed routing. OpenRouter's model fallbacks are a one-field change: send a models array in priority order instead of a single model, for example {"models": ["~anthropic/claude-sonnet-latest", "gryphe/mythomax-l2-13b"], "messages": [...]}. It falls back on context length validation errors, moderation flags, rate limiting and downtime. Billing follows reality: "requests are priced using the model that was ultimately used, which will be returned in the model attribute of the response body." Note the constraint if you use the Anthropic-style fallbacks parameter instead: maximum three entries, model field only, and it cannot be combined with models.

Self-hosted routing. LiteLLM's Router is open source and keeps the third party out of your request path. The parameters that do the work are num_retries, allowed_fails (default 3 failures per minute before a deployment is cooled down), cooldown_time (default 5 seconds) and routing_strategy, where simple-shuffle is the default and the documentation's recommendation for production. Fallback ordering comes from the deployment list, lowest order first.

The choice is honest and small: OpenRouter puts another company between you and inference in exchange for about ten minutes of work, LiteLLM keeps the path yours in exchange for config you have to maintain and test. Either way, decide now which model is lane two, because that is a quality decision, not an availability one. If your fallback is a cheaper tier, read our price map for open-weight models first, and if you have not re-run your model selection recently, the token math is the place to start.

Step 5: Decide what degrades and what queues

Failover is not always right. A summarisation job that runs nightly should queue and retry, not silently produce lower-quality output from a weaker model. A support-reply draft should fail over instantly, because a slightly worse draft beats no draft. Write the rule down per feature, in three columns: feature, behaviour when the primary is down, what the user sees. The third column is the one teams skip, and it is the one that decides whether an outage costs you 50 minutes or a refund request.

Step 6: Read the SLA before you rely on it

Managed model services do publish service levels, and the remedy is smaller than people assume. The Amazon Bedrock SLA pays service credits on a tier schedule: 10% for monthly uptime below 99.9% but at or above 99.0%, 25% below 99.0%, 100% below 95.0%. Credits are "your sole and exclusive remedy," and the exclusions cover force majeure, your own configuration, and failure to follow documented best practices. On a $400 monthly inference bill, a 10% credit is $40. That is not compensation for a bad day in your product. It is a reminder that continuity is your engineering problem, which is the same conclusion the platform dependency audit reaches from the business side.

The 30-minute drill

Book it for this week. In staging, revoke or invalidate your primary provider key and use the product normally for ten minutes. Watch three things: does the fallback fire, how long does the first request take before it does, and what does the user actually see while it happens. Then restore the key, note what surprised you, and fix that one thing. Bookmark both status pages while you are there, because the first 30 seconds of the next outage are always spent deciding whether the problem is theirs or yours.