ChatGPT, Claude, and Grok all suffered outages within three hours on Thursday, September 3, 2026. By lunchtime, a common explanation was that Microsoft Azure's East US region had failed and taken all three services down. None of the companies running those services had supported that explanation.
The available reports describe a routing error at OpenAI, an infrastructure issue at Anthropic, and a compute center outage at SpaceXAI. There may be a connection between the Claude and Grok failures, but it remains unconfirmed. As of the morning of September 4, the evidence doesn't establish a shared cause.
How the outages overlapped
This timeline uses UTC and draws on vendor status pages and Thomas Claburn's reporting at The Register.
- 12:37: Anthropic opened an incident for elevated errors on Claude Sonnet 5. It closed the incident at 12:56.
- 13:26: Anthropic opened a second incident covering Claude Mythos 5.1, Fable 5.1, and Opus 5. By 13:50, it had added Opus 4.8 and Opus 4.6.
- 13:30: Grok went down on X and in its iOS and Android apps. SpaceXAI later attributed the failure to an outage at its Memphis compute center.
- 14:43: OpenAI reported a routing error that made ChatGPT and Codex unavailable for some users. A fix was in place by 15:17.
- 16:16: Anthropic declared that impact had ended for all models. Grok returned around 17:00, roughly three and a half hours after it went down.
Those reports offer different levels of detail. OpenAI identified a routing problem. SpaceXAI identified the affected facility. Anthropic described an “infrastructure issue” without specifying what had failed.
The Azure explanation lacked vendor support
Downdetector showed a spike in Azure reports during the same period, and several outlets treated that as evidence of a common cause. But user-submitted reports don't establish which infrastructure failed. People can report an Azure problem because an application stopped working, without knowing whether Azure caused it.
The Register checked the Azure, AWS, and Google Cloud status pages and found nothing relevant. Cloudflare, which all three AI companies use in some capacity, said it had no service disruption of its own. As of the morning of September 4, Microsoft had posted no incident for September 3.
Gemini stayed available. That was also read as evidence that Google Cloud was safe while Azure was the shared point of failure. Gemini's availability doesn't establish the cause of another service's outage.
A possible connection between two of the failures runs through Memphis. In its apology on X, SpaceXAI also apologized to affected compute partners. Karissa Bell at Engadget reported that Anthropic leases compute from SpaceXAI and noted that Claude's second incident opened within minutes of Grok's outage.
Neither company has confirmed that the two incidents were connected. If they were, the morning could have involved two underlying outages rather than three. That still wouldn't provide evidence for the Azure explanation.
Elon Musk said the company was taking corrective action to prevent a recurrence. SpaceXAI had not named the cause of the Memphis failure.
Apps using the models inherited the disruption
Cursor shows how these failures affected products built on model APIs. Its status page logged four separate incidents on September 3, all labeled as upstream problems:
- An incident for all Grok models, Automations, Cloud Agents, Grok Bot, and Review Agents opened at 13:41.
- An incident for Anthropic models opened at 14:17.
- An incident for OpenAI models opened at 15:17.
- A separate incident affecting Grok 4.6 lasted until 19:21.
The reported failures were outside Cursor's own systems, but its users still experienced a bad day lasting roughly five hours. Cursor couldn't prevent its providers from failing, even though offering alternative models gave users a way around some of the disruption.
For products tied to a particular model API, that provider's availability limits what the product can deliver. On Thursday, Grok was unavailable for roughly three and a half hours. A chat application may be able to display an error and accept a fresh request later. An agent that has spent forty minutes working on a job has a more difficult recovery problem. Some state may already be written, and a retry needs to know where execution stopped.
OpenAI's closing note supplied a smaller example of the same issue: some Codex remote control users would need to pair their phones again after the incident. Restoring the service doesn't necessarily restore every session cleanly.
Anthropic gave the most useful recovery updates
Anthropic's status page was the most useful of the three for deciding where to send requests. It named affected models rather than reporting only a broad product outage.
At 15:25, Anthropic said that only Opus 4.8 and Opus 5 remained affected and that everything else had recovered to baseline. For an application with tested alternatives, that was actionable information: requests could go to Sonnet 5 or Fable 5.1 while the affected Opus models stayed out of the routing pool. The incident ran from 13:26 to 16:16, with seven updates to the page.
OpenAI provided a cause. “Routing error” doesn't explain much, but it identifies a technical component rather than merely saying the service was unavailable. A fix landed 34 minutes after the incident opened, although the incident itself remained open into the afternoon.
SpaceXAI provided a location. Knowing that the Memphis compute center had an outage helps identify the affected infrastructure, but it doesn't explain what broke. Three and a half hours is a long disruption to leave without that explanation.
As of September 4, none of the three companies had published a postmortem.
Preparing for a provider failure
The controls needed here are familiar infrastructure practices. Teams that started building on model APIs in the past two years may not yet have tested them against an extended provider outage.
- Treat a model provider like any other critical upstream dependency. Use health checks, a circuit breaker that stops repeated requests to a failing service, a fallback list ordered by cost, and a timeout that determines when to switch. Anthropic's model-level updates offered useful information for fallback decisions. A Downdetector spike couldn't provide the same model-specific guidance.
- Understand where the compute comes from. Anthropic runs on AWS, Google, and Lambda's Texas capacity, as well as SpaceXAI hardware according to Engadget. A failure at a facility absent from the customer's contract can still affect the model being purchased. The public explanation may say only “infrastructure issue.”
- Test alternative models before they are needed. Sonnet 5 was affected for only 19 minutes that morning. That made it a possible fallback, but only for applications whose prompts, tool schemas, and output parsers worked with it. Discovering incompatibilities during an outage defeats much of the purpose of having an alternative.
- Make agent jobs resumable. Retrying a chat completion is different from recovering a 40-step job that failed at step 27. Save checkpoints and make steps idempotent, meaning that repeating a step doesn't create an unintended additional effect. Recovery should assume that the provider may return without retaining the session's state.
Multi-provider routing is often sold as a way to reduce cost. Thursday made a stronger case for availability. Cursor's users could switch models manually as OpenAI, Anthropic, and SpaceXAI experienced overlapping disruptions. A product pinned to a single provider had no equivalent option.
The prediction is that the eventual postmortems will describe two underlying outages rather than three, with neither attributed to Azure. That depends on an unconfirmed connection between Anthropic and SpaceXAI. A further expectation is that the next cluster of AI outages will again be blamed first on a major cloud provider, before the incident reports establish what happened.
