Sometime around mid-morning Eastern on Thursday, a large share of the world’s commercial AI capacity stopped answering. OpenAI’s ChatGPT, Anthropic’s Claude, xAI’s Grok and Google’s Gemini all logged service disruptions inside the same window, with Downdetector showing error reports spiking across the platforms within minutes of one another.
The specifics, where the companies published them, are narrow and unglamorous. OpenAI detected elevated error rates across ChatGPT and Codex at roughly 10:58 UTC — 15 affected components on ChatGPT, four on Codex — applied mitigations within about 24 minutes, and closed the incident at 11:22. Anthropic reported elevated errors on requests to Claude Mythos 5.1, Fable 5.1 and Opus 5, with most models returning to baseline error rates while Opus 4.8 and Opus 5 lagged. Google’s Gemini disruption hit thousands of users. Users across the platforms got failed connections, severe latency, or plain internal server errors.
What nobody has established — and this matters — is a common cause. Four companies running four different training stacks, four different inference fleets and four different cloud arrangements are not supposed to fail together. No lab has published a shared root cause, and there is no public evidence of one. Reports that AWS was also affected in the same window point at a shared-infrastructure explanation, but that is an inference, not a finding.
Our take. The outage itself was short and unremarkable. The correlation is the story. Every enterprise AI resilience plan written in the last eighteen months has the same architecture: primary model, fallback model, different vendor. That design assumes vendor failures are independent events. This morning they were not — whether because of shared cloud substrate, shared CDN and networking layers, or coincidence. If you cannot tell which of those three it was, you cannot price the risk, and if you cannot price it, your failover plan is a hope with a config file attached.
Why a 24-minute outage is worth your attention
Twenty-four minutes of degraded chat is a nuisance. Twenty-four minutes of degraded agents is something else. The workloads that moved onto these APIs in 2026 are not people typing questions — they are coding agents mid-task, support queues auto-triaging, document pipelines running unattended overnight. Those systems handle a hard 500 badly. They retry, they burn context, they half-complete, and in the worst designs they act on a partial result.
The practical question is not “was our vendor up.” It is: when the primary and the fallback both returned errors at 11:05, what did our agent do? Most teams cannot answer that, because the failover was never tested against simultaneous failure — only sequential.
What to watch
- Post-incident reports. If the labs publish root causes and they turn out to be unrelated, this was coincidence and the independence assumption survives. If two or more point at the same upstream provider, a lot of architecture diagrams need redrawing.
- Whether AWS confirms an incident in the same window. That is the single fact that would turn correlation into explanation.
- Enterprise contract language. Watch for procurement teams starting to ask about infrastructure overlap between their primary and fallback vendors — a question almost nobody asked before today.
- Your own retry logic. Cheapest possible action this week: run a game day where both model endpoints return 503 simultaneously and see what your agents do.
Nothing here suggests a systemic fragility that was not already there. It suggests that the fragility became visible for twenty-four minutes, and that most people watching mistook it for a bad morning rather than a data point.