ChatGPT, Claude and Grok went down on the same day: correlated failure is now the default risk

On 3 September, r/LocalLLaMA posted a three word observation that a lot of teams should treat as a design review: Apparently ChatGPT, Claude, and Grok were down.

Another thread the same day made the point more bluntly, listing three subreddits reporting three separate vendors failing and then noting that local AI cannot be disabled. A Claude user wrote that all of ChatGPT's websites went down for a lot of people and that they were fielding requests from people and pointing them at Claude, which is exactly the substitution behaviour that turns one vendor's incident into everyone's load spike.

All of this on the day OpenAI launched GPT-6 Astra.

The three day incident log is the real story

Take just one vendor's public record across 1 to 3 September, as surfaced in r/ClaudeAI incident threads:

• 1 September: degraded performance on claude.ai, affecting Claude for Microsoft Office 365.
• 1 September: degraded performance on platform.claude.com and docs.claude.com.
• 1 September: delays in credit purchases, where accounts that hit a zero balance and bought credits still received credit balance is too low errors, across a nine hour window.
• 2 September: elevated errors on Sonnet 5.
• 3 September: elevated errors on Sonnet 5 again.
• 3 September: elevated errors on Mythos 5.1, Fable 5.1 and Opus 5 at once.

Six incidents, three days, one vendor, during a flagship launch week. And separately, capacity pressure showing up as model level unavailability: an Opus overloaded thread where the user's workaround was to move to Fable 5.1, which happened to be working.

In our own tracked Reddit corpus, provider outage mentions rose from 2 in 29 to 31 August to 10 in 1 to 3 September. Small absolute numbers, and the direction is consistent with everything above.

Why independent vendors fail together

The comforting model is that three vendors mean three independent probabilities. It is wrong for two reasons.

Shared substrate. These services sit on overlapping cloud regions, CDNs, DNS providers and identity systems. A dependency below all of them takes them all.

Shared demand shocks. This is the one people miss. A flagship launch produces correlated traffic across the entire category: everyone opens the new model, everyone reruns comparisons, everyone's agents get pointed at the new ID at the same time. Then the vendor whose model is degraded sheds users onto competitors, as that Claude user described in real time. Launch week is peak load week for every vendor simultaneously, not just the one launching.

Add a third, subtler factor. Anthropic's own release notes for Fable 5.1 acknowledged compute scarcity around the top tier, and a widely read r/ClaudeAI post argued the flagship is offered at a nearly unusable scale because of exactly that. Frontier models are being launched into capacity they do not fully have.

The failure mode nobody plans for

Read that credit purchase incident again. Users who had run to zero, paid, and then received errors saying their balance was too low.

That is not an inference failure. Your model calls were fine. The control plane that decides whether you are allowed to make them was not. No amount of model level fallback helps if the billing path fails, and almost nobody tests it.

The general lesson: enumerate the dependencies that can stop you serving, not just the ones that serve. Inference endpoint, authentication, quota accounting, billing, status reporting, and your own key management. Each is a separate outage class.

What correlated risk means for architecture

Multi provider is necessary and not sufficient. Two vendors on the same cloud region are one failure domain. Spread across vendors, hosts and regions, and know which of your fallbacks are genuinely independent. We wrote the mechanics up in handling LLM platform outages and failing over in two minutes.

Open weights are the strongest hedge available. The same model served by many independent providers gives you real diversity, because a bad hour at one host is not a bad hour at all of them. That is the operational upside of the August open weight wave, and the reason to know your model's provider variance in advance, which we measured in same weights, twelve providers.

Local capacity is a legitimate tier. The r/LocalLLaMA point stands on its merits during a correlated incident. A modest local model handling classification and extraction keeps a product partially alive when every hosted frontier is erroring.

Do not schedule migrations into launch week. The window with the newest model is the window with the least stable capacity. Evaluate then, promote later.

The controls that matter

• Fallback policies with candidates spanning different vendors and hosts, not different models from one lab.
• Load balancing policies and latency routing so degradation is shed automatically rather than after someone reads a status page.
• In flight rate limits and API limits so a slow provider cannot hold your whole concurrency budget in hanging requests, which is how a partial outage becomes a total one.
• Alerts, performance monitoring and error codes on per model error rate, so you detect it before your users and before the status page updates.
• Logs retained across the incident, because the postmortem question is always which requests failed and which silently degraded.

The honest summary

Three vendors failed in one window, one vendor logged six incidents in three days, and a flagship model was overloaded on arrival. None of that is unusual any more, and none of it is going to improve while capacity trails demand at the frontier.

Design for correlated failure rather than independent failure. That means genuine provider diversity, a cheap tier that can absorb work, limits that contain slow paths, and alerting on your own error rates instead of trusting a status page. It also means accepting that the day a major model launches is the least reliable day of the quarter.

For the architectural version of this see zero downtime LLM architecture beyond basic fallbacks and reliability aware routing.

Start routing on Requesty and stop depending on one vendor's good day.