Why did ChatGPT, Claude, and Grok go down together? The technical story behind a mass AI outage

3 September timeline: what each vendor actually reported

Align on each vendor’s own status page before inventing one “shared incident.” xAI moved first: around 9:30 ET, Grok failed on Android, iOS, and web; replies on X said the model was overloaded and to try later or pick another. Afterwards xAI tied the event to its Memphis data center, not a vague “we are investigating.” Keep that sentence. At least one vendor gave a hall-level explanation that a later Azure narrative should not swallow whole.

Anthropic reported a partial outage from an infrastructure issue: consumer Claude, Claude Code, and the public API saw elevated errors in the same stretch. Their public timeline claimed a cause in about fifteen minutes and recovery around 12:15, with a later blip on a single model. OpenAI came later: around 10:43–11:00 the status page said ChatGPT and Codex had elevated errors and degraded performance. The blast radius was not just the chat box — login, file upload, voice, search, Deep Research, and image generation were listed. OpenAI was also teasing Astra that day, so baseline traffic was already high. After a mitigation, the incident was marked resolved around 12:55.

The same morning, coding agents such as Cursor that depend on Claude and Grok reported their own outage — not a fourth frontier model dying, but a downstream runtime losing two of its backends. Gemini saw a spike in user complaints without an official confirmed outage. Ars Technica stacked four names because the complaint curves stacked, not because Google published an incident. Overlap is not one root cause. A DownDetector spike is not a vendor acknowledgement.

Split the record: official facts, infra clues, guesses that are not a root cause

Split the evidence into three layers before asking why it was simultaneous. Layer one is official: all three confirmed failures in their windows; Grok pointed at Memphis; Claude said infrastructure issue; ChatGPT / Codex said elevated errors. As of this writing there is no joint RCA and no vendor naming another. The Verge’s update only confirmed recovery and the lack of a unified explanation.

Layer two is infrastructure clue. Several outlets and status aggregators noted a Microsoft Azure complaint spike in the same hours; some reports described ingress failures in Azure East US around 10:26 PT (1:26 ET). East US carries a large share of enterprise AI traffic, and OpenAI, Anthropic, and xAI all run meaningful inference and networking on Azure. If ingress, load balancing, or regional routing flinches, different apps still present as 502s, timeouts, and failed logins together. That explains why it looked simultaneous. It is still a clue, not a signed RCA.

Layer three is guesswork you should not build on: that Azure throttled rivals on purpose, that the three firms scheduled a joint maintenance, that Memphis and East US are proven to be one incident. Public material does not support those readings. Two engineering sentences survive. First, consumer AI already shares a handful of cloud regions and a handful of front doors. Second, when the first brand dies, user switching and client retries shove load onto the next — even if that next hall is healthy.

Shared cloud and ingress: why it looked simultaneous

In 2026 the front-door models look like three companies, three products, three tokenizers. Underneath they often share accounts, regions, GPU quota, global anycast ingress, identity, and metering. Training can live in a private hall. Inference wants to be near users, elastic, and procurable, so Microsoft Azure became the common denominator. Gemini mostly staying up is not proof that “Google’s model is stabler.” It is the cleaner fact that its primary path runs on Google Cloud and was not fighting for the same East US front door.

So “simultaneous outage” is often the language of ingress and control plane, not “three Transformers crashed at once.” ChatGPT listing Codex, uploads, voice, and Deep Research together looks like a shared gateway or identity layer, not one chat decoder. Claude tying chat, Claude Code, and the API to one infrastructure issue is the same signal: many product names, few front doors. You do not need the official RCA to change the design. Assume regional ingress can fail as a unit.

Cascades, retry storms, and Memphis

Shared cloud explains the overlap. Cascade explains why the second and third brands looked worse. When ChatGPT dies, the default next step is not waiting — it is opening Claude or Grok. Tens of millions of sessions changing vendor in minutes is a traffic spike aimed at an ingress that may already be hurt. Clients and Agent frameworks make it worse: retry immediately on timeout, rotate keys, switch models, no jitter, no “this is infra, stop hitting it” signal. Classic retry storm. The first vendor’s outage becomes “inexplicable overload” in the second vendor’s logs.

Keep Grok’s Memphis note in its own column. xAI publicly tied the failure to its own data center, and it started earlier than ChatGPT’s status page. It may be an independent accident that merely overlapped; it may share power or upstream connectivity with a wider event. Until there is a joint timeline, write them in parallel, do not merge them. The engineering moral is sharper: if your failover list is “when OpenAI dies, cut to xAI,” that policy died on Grok first that morning.

Cursor’s outage that day is the product shape of a cascade. The editor does not train a model; it treats Claude and Grok as runtimes. When they flinch, completions, agents, and tool calls stop together. Most internal Agents in 2026 look like this: MCP tools, A2A tasks, your own HTTP JSON, still terminating on two or three cloud models. The single point of failure is not your business code. It is the default model field. See MCP and JSON Schema and stateless MCP.

The control plane is more fragile than the model

A healthy GPU cluster does not make a user request succeed. Login, upload, voice, and search failing together means the gateway, identity, object-storage front door, or shared edge broke — not one decoder layer. “Model overloaded” on the page is often a false symptom: what is actually overloaded is ingress connections, certificate checks, or the token service. Status pages lag; users see DownDetector first. When you debug, do not stare at the model name. Read httpStatus, code, and whether the envelope is retryable.

Normalizing vendor errors into one envelope is more useful than a toast that says “AI failed.” The JSON below only says which provider, which status, and whether to retry. The business layer should not parse each vendor’s prose. Prose goes to logs. The envelope goes to the breaker.

{
  "ok": false,
  "provider": "openai",
  "httpStatus": 503,
  "code": "elevated_errors",
  "retryable": true,
  "occurredAt": "2026-09-03T15:00:00Z",
  "message": "ChatGPT and Codex are returning elevated errors"
}

The same morning you may see OpenAI’s elevated errors, Anthropic’s infrastructure issue, and xAI’s overloaded at once. Field names differ; the decision should not: retryable errors enter cooldown, non-retryable errors switch vendor, envelopes that miss the Schema are hard failures — do not regex an HTML error page. Drop real failure samples into JSONVue: format to see fields, validate for syntax, JSON Schema for required keys, Diff to see which keys each vendor omits. When the cloud generation layer goes dark, local parsing still works. That is the point of in-browser tools.

For Agent / JSON pipelines: multi-vendor is not a slogan

“Multi-cloud” on a slide did not help that morning. Working multi-vendor is a runtime policy: a primary, an explicit fallback order, breaker thresholds, and one error envelope every vendor must fill. Do not hammer the same vendor twenty times. Do not implement fallback as “pick a random survivor.” Gemini being usable that day is because it did not share the same ingress fate — which is exactly why the backup list needs a vendor whose primary path is different, not three names that all land on Azure East US.

The policy itself should be JSON, versioned apart from the business Schema. The config below does not care about model trademarks. It cares who you hit first, who you hit next, at what error rate you cut, and which envelope keys are a hard gate.

{
  "policy": "failover",
  "primary": "openai",
  "fallbacks": ["anthropic", "xai", "google"],
  "circuitBreaker": {
    "errorThreshold": 0.3,
    "windowSeconds": 60,
    "cooldownSeconds": 120
  },
  "errorEnvelope": {
    "required": ["ok", "provider", "code", "retryable"]
  }
}

Easy to miss: tool-argument JSON and final-answer JSON are different hops. MCP tools/call, OpenAI function arguments, and your own HTTP body fail in different shapes when the model is gone. If “model unavailable” and “arguments failed Schema” become the same toast, the postmortem turns the wrong knob. Local validation still matters, for the same reason as in Structured Output: shape and availability are not the same layer. After the cloud recovers, keep that morning’s failure envelopes as fixtures. They beat another recap email.

FAQ

Summary and next steps

3 September compresses to one line: consumer AI is already an ingress service on shared cloud. The trademarks differ; fate can still overlap on one regional path. Memphis, East US ingress, and user switching may be three threads or they may touch. Until an official RCA, do not crush them into a plot, and do not treat them as unrelated bad luck.

Next step is concrete: collect failures as JSON, write failover as policy, treat breaker thresholds as replayable config. Models will recover and status pages will go green. Whether your Agent goes silent again the next time a regional front door flinches depends on whether "model": "the only one" is still hardcoded.