On the morning of September 3, three of the largest frontier labs went down inside the same 77-minute window. Anthropic started investigating errors at 13:26 UTC. xAI logged an outage four minutes later. OpenAI's routing error kicked in at 14:43 UTC. Downdetector picked up more than 14,000 reports, and downstream tools like Cursor went with them.

The interesting part is not that it happened. It is that the causes were unrelated. OpenAI blamed a routing error. xAI pointed at a compute centre in Memphis. Anthropic said nothing beyond its status page. No shared cloud, no shared CDN, no single upstream failure anyone has named publicly.

That detail matters more than the downtime did.

Independent providers are not independent failures

Most teams that thought about LLM resilience at all landed on the same answer: keep a second provider configured, flip to it when the first one breaks. It feels like the same move as running two availability zones.

It isn't. Two AZs fail independently because someone engineered them to. Two AI labs have no such contract with each other. They just happen to be different companies. When you assume their failures are uncorrelated, you are relying on luck, and September 3 is what a bad roll looks like.

The labs also share more than the org chart suggests. Overlapping GPU supply, overlapping cloud regions, similar traffic patterns from the same set of agent tools hammering them at the same hours of the working day. Correlation does not need a single root cause. It just needs enough shared surface area.

What actually broke was the assumption, not the API

Here is the test worth running this week. Point your staging environment at a dead endpoint and watch what your product does.

In most codebases we see, one of three things happens. The request hangs until something upstream times out at 30 or 60 seconds, and the user stares at a spinner. Or the failover path fires and immediately hits a rate limit on the backup provider, because nobody warmed the quota. Or the fallback works, returns a differently shaped response, and something three functions down the stack throws on a field that isn't there.

The second provider was never the hard part. The hard part is everything the code does while it waits, and everything that assumes the response arrives.

Design for absence, not for a swap

The teams that sailed through September 3 mostly weren't the ones with clever routers. They were the ones whose products still did something useful with no model available.

A few things worth building:

Aggressive, per-call timeouts. If a completion is worth 8 seconds, cut it at 8 seconds. Don't inherit a 60 second default from your HTTP client.
A degraded mode that ships. Cached results, the last known summary, a template, a queue with an honest message. Empty state beats an error page.
Idempotent, resumable work. If the outage hits mid-workflow, the job should pick up where it stopped rather than restart or half-commit. Durable execution earns its keep on days like this.
Contract tests on both providers. Same schema, same validation, run in CI. A failover you have never executed is a hypothesis.
Pre-provisioned backup quota. Rate limits on a cold provider are the most common way failover fails at exactly the wrong moment.

None of this is exotic. It is the same reliability work we have always done for payment gateways and third party APIs. The only thing that changed is that the dependency now sits in the critical path of features people think of as core product.

Treat the model like any other network call that can vanish. Because on September 3, three of them did at once, for three completely different reasons.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!