# ChatGPT, Claude and Grok down at once: your failover plan

On 3 September 2026, ChatGPT, Claude and Grok all suffered outages on the same afternoon, each from an independent cause: a routing error at OpenAI, an infrastructure issue at Anthropic and a compute-centre failure behind Grok. A runtime failover plan for Azure teams: Foundry's model router with automatic fallback, APIM's AI gateway and circuit breaker, what redundancy really costs, and the Data Zone and DORA constraints that shape it.

- Published: 2026-09-06 · Category: AI & Cloud Infrastructure · Tags: AI Failover, Resilience, Microsoft Foundry, Model Router, Azure API Management, DORA, EU Data Zone, Multi-Model, Outage
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/chatgpt-claude-grok-down-at-once-your-failover-plan

On Thursday 3 September 2026, the three most-used AI assistants in the western market all had outages on the same afternoon, European time. Anthropic's status page logged elevated errors on Claude Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8 and Opus 4.6 from 13:26 to 16:23 UTC, just under three hours. OpenAI reported a routing error that made ChatGPT and Codex unavailable for some users from roughly 14:43 to 15:17 UTC. xAI's Grok was down from around 13:30 UTC after what the company later described as an outage at its Memphis compute centre. For about half an hour in the middle of the European workday, a team that had standardised on any one of the big three assistants, or on all of them, was working without it.

The interesting part is not the outage. It is that the three incidents had three unrelated causes, and that this coincidence is a better argument for failover engineering than any shared-infrastructure meltdown would have been. If one cloud region had taken all three down, the fix would be a procurement question: pick vendors on different clouds. Independent same-day failures teach a harder lesson. Every provider fails, on its own schedule, for its own reasons, and the only defence that works against all of them at once is architecture on your side of the API.

## Three outages, three causes

| Service | Window (UTC, 3 Sep) | Stated cause |
| --- | --- | --- |
| Claude (Mythos 5.1, Fable 5.1, Opus 5/4.8/4.6) | 13:26 – 16:23 | "Infrastructure issue" causing a partial outage |
| Claude Sonnet 5 (separate incident) | 12:37 – 12:56 | Elevated errors, mitigated within 20 minutes |
| ChatGPT and Codex | ~14:43 – 15:17 | Routing error, per OpenAI's statement |
| Grok | From ~13:30 | Outage at the Memphis compute centre |

Speculation about a common cause circulated all afternoon, and it was reasonable speculation: shared CDN, shared cloud, shared dependency somewhere in the stack. It did not hold up. Cloudflare, which fronts all three services, stated it was not experiencing significant disruptions. The status pages of Azure, AWS and Google Cloud showed no relevant incidents in the window. A routing error, an infrastructure fault and a compute-centre failure at three different companies happened to land within ninety minutes of each other.

## The arithmetic of independent failures

Independence cuts both ways, and the maths is worth doing explicitly because it is the business case for everything that follows. Suppose a single model provider is unavailable 0.5% of the time, about 3.6 hours in a month. That is not an accusation aimed at anyone; pick your own number from your own incident log. A workload that depends on that one provider inherits that availability, full stop. Now put a second, independent provider behind an automatic failover. Both being down at the same moment has a probability of 0.5% times 0.5%: 0.0025% of the month, or a little over one minute. Two mediocre providers behind a working failover beat one excellent provider with none.

The catch is the word independent. If both of your models are served from the same region of the same cloud, or both sit behind the same gateway you operate, or both calls originate from an application that itself runs next to one of them, the multiplication stops being honest. September 3 was a genuine display of independence between providers. Your own architecture may quietly reintroduce the correlation, and the single shared component in front of everything (for most teams, the CDN or the API gateway) becomes the number that actually bounds your availability.

## Know which serving path you are on

One clarification matters before designing anything. Thursday's incidents hit the providers' own front doors: claude.ai and the Anthropic API, chatgpt.com and Codex, grok.com. A model deployment in Microsoft Foundry is a different serving path with its own incident history, its own SLA and its own failure modes. Some Azure customers noticed nothing on Thursday. That is not a reason for comfort; it is a reason to write down, per workload, which serving path each model call takes: the provider's first-party API, a Foundry deployment, or a third-party route. Teams are often surprised by their own inventory. The chat feature calls Foundry, the batch summarisation job someone shipped in June calls the Anthropic API directly with a key from a personal account, and the two have very different behaviour on a day like 3 September.

We covered the contractual version of this problem on Tuesday, in the wake of OpenAI's Cursor decision: keeping model names out of application code and an eval suite ready so you can leave a provider deliberately. A three-hour outage is the runtime version. The exit plan operates over weeks; the failover has to operate in seconds, without a human in the loop. They share an abstraction layer, and they are otherwise different pieces of engineering.

## The runtime failover toolbox on Azure

### Model router: failover you get by deploying it

The lowest-effort option is Microsoft Foundry's model router, which as of the current 2025-11-18 version routes across models from OpenAI, Anthropic, xAI, DeepSeek and Meta behind a single deployment. Its headline feature is cost-based routing, but the relevant feature this week is built-in automatic failover: when an underlying model has transient issues, the router transparently redirects the request to the next most appropriate model. It is enabled by default and requires no configuration.

Two operational details decide whether it fits your workload. First, the model subset feature doubles as your fallback policy: whatever subset you configure is the set the router may fail over to, so a subset needs at least two models before the fallback does anything, and an unconfigured default deployment may route to models your governance process never approved. Pair it with the Azure Policy integration if your organisation restricts deployable models. Second, Claude models are the exception to the router's zero-setup story: they must be deployed separately from the model catalog before the router can invoke them. Budget for the router's own per-prompt charge on top of the underlying model tokens, and note the context-window caveat: the effective limit is that of the smallest model in your subset, so a long-context request can fail depending on where it lands.

### API Management's AI gateway: failover you control

Teams that want explicit control put Azure API Management in front of their model deployments and use its backend pool features. The load balancer supports priority-based distribution, which maps directly onto the classic Azure OpenAI capacity pattern: provisioned throughput as priority one, pay-as-you-go Standard as overflow, a second region or second provider as priority three. The circuit breaker trips on backend failures and honours the Retry-After header the backend returns, so a struggling deployment gets taken out of rotation and probed for recovery at the pace it asks for rather than hammered by retries.

Cross-provider failover through one endpoint used to require format-translation glue, because an OpenAI Chat Completions payload is not an Anthropic Messages payload. That glue is now a product feature: APIM's unified model API, in preview, exposes multiple backends through a single OpenAI-compatible endpoint and handles the translation, with the Anthropic Messages API supported in the v2 tiers and even non-Azure backends such as Amazon Bedrock in scope. On a day like Thursday, that is the difference between an incident channel full of deployment questions and a circuit breaker doing its job at 13:27.

### The application layer: degrade on purpose

Gateways handle the case where a fallback model can serve the request. Some of Thursday's pain was in workloads where it cannot. An agent halfway through a twelve-step task holds state that a different model may continue badly; a compliance-reviewed summarisation flow may be approved for exactly one model and no other. For those, the failover is not a second model, it is a designed degraded mode. Queue the work and drain it after recovery instead of failing it. Serve cached or semantically-cached answers where staleness is acceptable; APIM's semantic caching does this at the gateway. Put AI features behind flags so the product degrades to its non-AI behaviour instead of erroring. A chat assistant that says "assistant unavailable, your draft is saved" keeps the customer; one that spins keeps nothing.

## What failover actually costs

The pleasant surprise in AI failover, compared with classic disaster recovery, is that the standby is nearly free. A second model on consumption pricing costs nothing while idle; there is no warm replica burning money the way a standby SQL instance does. The real costs sit elsewhere.

- **Cold caches.** Prompt caching is per model. A workload built around Anthropic-style cache reads at a tenth of the base input rate pays full price on every request the moment traffic shifts to a fallback, then pays again to warm the new cache. During a one-hour failover this is noise; budget for it anyway so the cost-anomaly alert does not become its own incident.
- **Evals for the fallback.** A fallback model you have never evaluated is not a fallback, it is a different incident. The eval suite you built for the exit plan earns its keep here: run it against the fallback on every prompt change, not once.
- **Output drift.** Downstream parsers, tool-call handling and safety filters tuned to one model's habits can misbehave on another's output. Structured outputs and strict schemas shrink this risk; they do not remove it.
- **Latency asymmetry.** Failover to a slower or more distant deployment can push a synchronous flow past its timeout, turning a model outage into an application outage anyway. Set the timeout budget end to end, not per hop.

## The Swedish and EU angle

**Failover must respect the same boundaries as the primary.** If a workload runs Data Zone Standard because your DPO signed off on EU-boundary processing, an automatic failover that quietly retries in a US region is a compliance incident wearing a resilience costume. This is where the model router's design helps: it routes only to eligible models honouring data zone boundaries, it supports Data Zone Standard deployments, and Sweden Central is on the supported list for both Global Standard and Data Zone Standard. The unresolved tension is cost: as we wrote on Monday, the EU Data Zone premium has doubled, so an EU-constrained fallback set is also the expensive one. Price the redundancy inside the boundary before an auditor asks why you built it outside.

**For financial entities, this is DORA homework, not hygiene.** The Digital Operational Resilience Act has applied since January 2025, and an LLM API that customer-facing workflows depend on is an ICT third-party service like any other: it belongs in the register of information, its concentration risk belongs in your ICT risk assessment, and a 3 September-style event belongs in your scenario testing. Finansinspektionen's supervisory questions will not distinguish between "our AI vendor was down" and "our payment provider was down". If a same-day, three-provider outage is not in your severe-but-plausible scenario list yet, Thursday wrote the scenario for you.

**NIS2-scope organisations should treat model dependencies as supply chain.** The directive's supply-chain security and business-continuity obligations do not name AI services, and do not need to. A dependency that can silently remove a business capability for three hours is exactly what the continuity requirements are about. The practical output is small: name the dependency, name the fallback, test it once.

## Checklist

- **1. Map every model call** to its serving path: first-party API, Foundry deployment, or third-party route. Include the shadow usage on personal API keys.
- **2. Classify each workload**: can it fail over to another model, must it queue and wait, or does it degrade to non-AI behaviour? These need different mechanisms.
- **3. Pick the mechanism per class.** Model router with a governed subset for interchangeable chat and summarisation traffic; APIM backends with priority load balancing and the circuit breaker where you need explicit control or PTU overflow; application-level flags and queues for the rest.
- **4. Keep the fallback inside your compliance boundary.** Data Zone workloads fail over to Data Zone deployments. Verify this by reading the routing config, not the marketing page.
- **5. Run the eval suite against the fallback** and wire its results into the same release gate as the primary.
- **6. Test the failover on a Tuesday.** Trip the circuit breaker deliberately in a non-production environment, watch the cache-cost spike and latency shift, and fix the timeout budget before a provider does the test for you.
- **7. If DORA applies to you**, put the model providers in the register of information and add the multi-provider outage to scenario testing.

## Conclusion

September 3 was a coincidence, and planning against coincidence is the whole job. Nothing that failed on Thursday was under any customer's control; whether Thursday mattered to them was decided entirely by architecture they had or had not built beforehand. The pieces are unusually cheap for a resilience problem: a router with failover on by default, a gateway with a circuit breaker, a fallback that costs nothing while idle. What they cost is the discipline of evals, boundary checks and one deliberate test. Three hours of Claude downtime is a good deadline to borrow.

## Sources

- [Anthropic status page: elevated errors for multiple models, 3 September 2026](https://status.claude.com/)
- [OpenAI status history: elevated errors across ChatGPT and Codex, 3 September 2026](https://status.openai.com/history)
- [The Register: ChatGPT, Claude, and Grok all go down at once](https://www.theregister.com/ai-and-ml/2026/09/03/chatgpt-claude-and-grok-all-had-outages-at-the-same-time/5294322)
- [Microsoft Learn: Model router for Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router)
- [Microsoft Learn: AI gateway capabilities in Azure API Management](https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt