Claude went dark for 3 hours — your fallback chain isn't optional
Claude's global 3-hour outage on July 29 was a capacity failure retries can't fix — here's the fallback chain to build before the next one.
On July 29, Claude's apps and API went down worldwide for roughly three hours, and Anthropic blamed capacity constraints under surging demand. If your prod path calls Claude directly with no fallback, you ate three hours of 500s. The takeaway: single-vendor LLM routing is now a reliability bug, not a convenience.
"Capacity constraints" is the important phrase here. This wasn't a bad deploy you can wait out in five minutes — it means Anthropic couldn't serve the load, and there's nothing your retry logic could do about it. Exponential backoff into a wall is still a wall.
What actually broke?
Calls to the Claude API returned errors for about three hours across both the consumer apps and the API, per Anthropic's own acknowledgment covered in the original report. Anyone whose request handler had `anthropic.messages.create()` as the only branch had no path to a response. Streaming endpoints hung, and anything with a synchronous user-facing call surfaced the failure directly.
The nasty part of a capacity outage: your retries make it worse. A naive client that retries 3x on 5xx triples the load Anthropic is already failing to serve. If you didn't have a circuit breaker, you were part of the thundering herd.
What I actually do about this
Route through an abstraction, not the SDK directly. I keep a provider interface with at least two backends — Claude and one of GPT-4o or Gemini — and a shared message schema so a failover doesn't mean rewriting prompts on the fly. The prompts aren't identical across vendors, so you pre-write both versions and pick at call time.
Concrete gotchas from doing this:
- Tool-use / function-calling formats differ between Anthropic and OpenAI. If you fail over mid-conversation, your tool schemas need translation or the fallback model chokes.
- Set an aggressive timeout (say 20s) plus a circuit breaker that trips after N consecutive failures and skips straight to the fallback. Don't wait for each request to time out.
- Log which provider served each request. When Claude comes back, you want to know how much traffic drained to the backup and what it cost.
- Cache aggressively for idempotent prompts. A cache hit is the only response that's up during a provider outage.
Should you use a single provider?
For a side project, sure — three hours down once in a while is fine. For anything with an SLA or a paying user hitting a synchronous endpoint, no. Treat every LLM provider as a dependency that will go fully dark for hours with no warning, because that's what just happened.
Verdict: build the fallback chain before you need it. It's an afternoon of work — a provider interface, two prompt variants, a circuit breaker — and it turns a three-hour outage into a degraded-but-alive window. I wouldn't ship an LLM feature to prod without it anymore.
FAQ
Will retries fix a capacity outage?
No. Capacity constraints mean the provider can't serve the load at all, so retries just add to the pile. Use a circuit breaker that trips fast and routes to a different provider instead of hammering the failing one.
What's the minimum viable fallback?
A provider interface with two backends, pre-written prompt variants for each, an aggressive timeout, and a circuit breaker. That's roughly an afternoon of work and covers the common case where one vendor goes fully down.
Do prompts port cleanly between Claude and GPT?
Not exactly. System prompt behavior and especially tool-use/function-calling formats differ, so write and test both versions ahead of time rather than translating live during an outage.