Four AI providers wobbled in the same three hours — and for thirty minutes there was nowhere to fail over to
TL;DR: On 3 September 2026, Anthropic (9:26 a.m.–12:16 p.m. ET), xAI (≈9:30 a.m.–1 p.m. ET) and OpenAI (10:43 a.m.–12:55 p.m. ET) all confirmed service incidents, while Google’s Gemini API showed elevated failures around 10:45–11:15 a.m. ET that Google never posted to its status page. No shared cause has been published by anyone. Line the timelines up and there is a roughly thirty-minute window when all four were impaired at once. For buyers: a multi-model strategy is only resilience if the alternatives fail independently — and almost nobody has measured whether theirs do. Audit shared dependencies, exercise the fallback path, add jitter to retries, and define a degraded mode before you need one.
The timelines
Individually, each of these was an ordinary incident. Collectively, they are the first real test of an assumption a great many teams have been quietly relying on.
| Provider | Window (ET) | Duration | Scope |
|---|---|---|---|
| Anthropic | 9:26 a.m. – 12:16 p.m. | ~2h 50m | Web app, API, Claude Code, Claude Cowork; several models |
| xAI | ~9:30 a.m. – ~1 p.m. | ~3h 30m | Web, mobile, plugins, API in two US regions |
| OpenAI | 10:43 a.m. – 12:55 p.m. | ~2h 12m | 15 ChatGPT components, 4 Codex components |
| Google Gemini | ~10:45 – 11:15 a.m. | ~30m | Elevated API failures; not posted to status page |
Anthropic reported elevated error rates across Mythos 5.1, Fable 5.1 and Opus 5, said it identified the cause about fifteen minutes in, and resolved at 12:16. OpenAI reported degraded performance, deployed a mitigation at 11:17 and declared resolution at 12:55. xAI’s incident spanned two US regions. Google’s is the odd one out: third-party monitoring showed a burst of failures, and Google’s public service health page recorded nothing.
Now overlay them. Anthropic’s window contains the whole morning; xAI’s runs longer still; OpenAI’s opens at 10:43; Gemini’s runs 10:45 to 11:15. Between roughly 10:45 and 11:15 a.m. Eastern, all four were degraded simultaneously. For half an hour, a team whose architecture said “if Claude fails, call GPT; if GPT fails, call Gemini” had a chain in which every link was impaired.
Why “no shared cause” is the alarming version
The instinct is to look for the single upstream failure — an AWS region, a Cloudflare change, a DNS provider, a BGP event. None has been identified, and no vendor has named one.
That absence is not reassuring; it is the opposite. A shared cause is a discrete, fixable, attributable thing. You read the post-incident report, you learn which dependency you did not know you had, and you route around it. Unexplained correlation offers none of that. It tells you the events moved together and gives you no mechanism to design against.
Three readings remain open, and they lead to different actions:
- Coincidence. Possible. Four independent incidents on one Thursday morning is unlikely but not remarkable across a year of operations.
- An unnamed shared dependency. Also possible. Three companies declining to publish a root cause is consistent with either embarrassment or ordinary reticence.
- Cascade. The most operationally interesting. When one large provider degrades, traffic and automated retries shift to the others within seconds. Load moves, and retry storms are rarely gentle. Under this reading, your own retry configuration is a participant, not a spectator.
Nothing in the public record settles which applies. The prudent posture is to treat correlation as unexplained rather than disproved.
The assumption that failed
The failover arithmetic everyone quotes assumes independence. Two providers at 99.9% availability combine to something near five nines only if their outages are uncorrelated. Correlation collapses that number quickly, and correlation is exactly what nobody measures.
The shared surfaces are more numerous than most architecture diagrams admit: cloud regions, DNS providers, CDNs, identity providers, transit paths, and — increasingly — the gateway sitting in front of everything. That last one deserves particular attention now that Stripe has acquired OpenRouter and the neutral router has an owner: a router is genuinely useful for switching providers, and it is also a single point of failure placed directly in front of your redundancy.
This is the reliability twin of a contractual point this desk made when OpenAI cut Cursor’s model access and multi-model turned out to be a contract rather than a setting. Having a second model configured is not the same as being able to use it — legally then, operationally now.
The blast radius grew while nobody re-examined it
A three-hour AI outage in 2024 meant a chatbot was slow. In September 2026 it means something else entirely, and Anthropic’s own incident scope makes the point: the failure covered Claude Code and Claude Cowork alongside the web app and API.
Coding agents stall mid-task. Document and research workflows halt. Agentic pipelines fail partway through multi-step work with recovery semantics that are frequently undefined — a category of fragility visible when a GitHub outage stalled agentic coding workflows in August, and again when a Microsoft 365 authentication failure took Copilot’s grounding with it.
It also lands in a month of unusually dense releases — Fable 5.1’s cache-read repricing on 1 September, Gemini 3.8 Flash on the 2nd, GPT-6 Astra on the 3rd. Rapid serving-stack change is a plausible contributor to instability. No vendor has said so, and asserting it would go beyond the evidence.
The uncomfortable structural note is that the concentration is increasing rather than easing. The same week, Nvidia confirmed its acquisition of Hugging Face, consolidating the open-weight distribution layer under the dominant compute vendor. Self-hosted open weights are one of the few genuinely independent fallbacks available — a path worth keeping open precisely because its failure modes are yours rather than shared.
What to do about it
Map your correlation surface. List every dependency your primary and fallback paths share — cloud, DNS, CDN, identity, transit, gateway. The ones you did not consciously choose are the ones to write down.
Exercise the fallback, do not merely configure it. Untested failover fails when it matters. Run it on a schedule, in production, deliberately.
Add backoff and jitter. Synchronized retries are how one provider’s degradation becomes the next provider’s load problem. If the cascade reading is right, this is the single change that stops you contributing to it.
Alert on your own error rates. On 3 September the fastest available signal for a Gemini customer was their own telemetry, because Google posted nothing. Vendor status pages are a lagging indicator and, in one of four cases here, not an indicator at all.
Define the degraded mode in writing, now. Which features are load-bearing and which vanish quietly. What gets queued and drained rather than lost. What the status message says. Decide it while nothing is broken.
Ask better procurement questions. What is the availability commitment, what credits attach, on what clock are incidents posted, and are post-incident reports published for customer-visible events? Anthropic withdrew its Priority Tier uptime commitment after August’s incidents, which makes the written terms behind Claude, ChatGPT and Gemini worth reading rather than assuming — and worth comparing directly when you weigh the major assistants against each other.
The bottom line
Three hours of degradation across three confirmed vendors is not an industry crisis, and the recovery times were unremarkable. Treating this as a scandal would miss what it actually offers, which is rare and useful: a free test of an assumption almost nobody validates.
Most teams that adopted a second model in the past year did so for pricing leverage or capability coverage and quietly booked it as redundancy too. On 3 September, for about thirty minutes, that redundancy was not there. Nobody has explained why, which means the next occurrence is equally unpredictable — and the work that makes it survivable is architectural, cheap, and entirely within your control.
Frequently asked questions
Was this one underlying failure, or four coincidences?
Nobody outside the four companies knows, and that is the substance of the story rather than a gap in it. There is no public evidence that a single cloud region, CDN, DNS provider or routing change caused all four events, and the incidents do not line up cleanly enough to make one obvious. Anthropic and xAI began within four minutes of each other; OpenAI began an hour and thirteen minutes later; Gemini's elevated failures fell in a narrow band in the middle. Anthropic stated it identified the cause and did not disclose it. OpenAI applied a mitigation without explaining what it mitigated. xAI published no root cause. Three plausible readings survive: genuine coincidence on a busy Thursday morning, a shared upstream dependency none of them named, or a cascade in which the first failure pushed traffic and automated retries onto the others and pressure did the rest. The third is the most operationally interesting, because it is the one your own retry configuration participates in. Without post-incident reports, treat correlation as unexplained rather than disproved, and design for it.
We already route across two providers. Are we covered?
You are covered against single-vendor failure, which is the common case and worth having. You are not covered against what happened on 3 September, and the difference is worth being precise about. Failover math assumes independence: two providers at 99.9% availability give you roughly five nines combined only if their outages are uncorrelated. If they share a cloud region, a DNS provider, a CDN, an identity provider, or a transit path, the real combined number is far worse and no dashboard will tell you. Then there is the layer above: if both models are reached through one gateway or router, that gateway is a single point of failure sitting in front of your redundancy. The practical audit takes an afternoon. List every dependency both paths share, including the ones you did not choose deliberately. Confirm your fallback path is exercised regularly rather than merely configured, because untested failover fails at the worst moment. And check your retry policy for exponential backoff and jitter, since aggressive synchronized retries are how a degradation at one provider becomes a load problem at the next.
Does this change which provider we should buy?
No, and treating it as a vendor scorecard would be the wrong lesson. Every provider involved had a bad morning, and the durations were broadly comparable — roughly two hours fifty for Anthropic, about three and a half for xAI, a little over two for OpenAI. There is no winner in that table. What the day should change is what you buy at the architecture layer rather than the vendor layer: an explicit degraded mode, a queue for work that can wait, and a clear answer to what your product does when no model responds. The vendor question that does matter is contractual rather than technical, and it is about what you are owed and told. Ask what the availability commitment actually is, what credits attach, on what clock incidents are posted, and whether post-incident reports are published for customer-visible events. Google not logging the Gemini degradation on its public status page is the detail with real procurement consequences here, because an incident that never appears on a status page cannot be claimed against, measured, or learned from.
What should we do if it happens again next week?
Decide now, in writing, because the middle of an outage is the worst time to decide what degradation is acceptable. Three questions cover most of it. First, which of your AI-backed features are load-bearing and which are enhancements — an enhancement should disappear quietly with a clear message rather than throwing errors or hanging. Second, what work can be deferred rather than lost: queue it, tell the user it is queued, and drain the queue when service returns, which converts an outage from a failure into a delay. Third, what your support and status communications say, prepared in advance, so you are not drafting them under pressure. Add one operational habit: alert on your own error rates against these APIs rather than waiting for a vendor status page, since on 3 September the fastest signal available to a Gemini customer was their own telemetry — Google never posted anything.
Is the industry getting less reliable as models get more capable?
The honest answer is that the evidence is mixed and the exposure is definitely growing. Model launches have been unusually dense — Fable 5.1 and Mythos 5.1 on 1 September, Gemini 3.8 Flash on 2 September, GPT-6 Astra and Muse Spark 1.3 in the same window — and rapid serving-stack changes are a plausible contributor to instability, though no vendor has said so and it would be unfair to assert it. What is not in doubt is that dependency has deepened faster than resilience practice. A year ago an AI outage meant a chatbot was unavailable. Now it means coding agents stall mid-task, document workflows stop, and agentic pipelines fail partway through multi-step work with unclear recovery semantics. Anthropic's incident explicitly covered Claude Code and Claude Cowork alongside the API. The reliability bar has not obviously dropped; the blast radius of an ordinary three-hour incident has grown considerably, and most teams have not revisited their failure handling since the era when the stakes were a slow chat reply.
Sources
- Info-Tech Research Group — Overlapping AI outages expose an enterprise resilience gap (incident timelines)
- MacDailyNews — Major AI platforms go down in unprecedented simultaneous outage (3 September 2026)
- AI Chat Daily — OpenAI, Anthropic and xAI hit near-simultaneous outages with no shared cause named
- Superpower Daily — Four major AI services suffer rare, overlapping outages
- Anthropic status page — service incident history
- OpenAI status page — service incident history
- xAI status page — service incident history
- Google Cloud service health — Vertex AI and Gemini API status
Related tool reviews
Questions or corrections? Email Pick Right. Want the full list? See all news.