When ChatGPT, Claude and Grok all went down

On Thursday 3 September 2026, three of the world's most used AI assistants — ChatGPT, Claude and Grok — became unavailable to many users inside the same few hours. The headline is simple. The detail underneath it is the part worth reading if any part of your business runs through an external service.

What actually happened

Drawing on the companies' own status pages and technology trade reporting, the sequence ran as follows (times in US Pacific):

Around 7:43 am — a routing error made ChatGPT and the Codex coding tool unavailable for a share of users on web and mobile.
8:49 am — OpenAI reported a fix applied and services recovering. By then most Claude models had returned to baseline, though Opus 4.8 and Opus 5 were still erroring. Grok's status page still showed an active incident.
12:38 pm — all three services were back to normal.

Two details usually dropped from the short version of this story:

Google's Gemini saw a spike in user reports but never confirmed an outage of its own.
Cursor, the coding tool that runs on Claude and Grok models, went down too. That is a second-order dependency in its purest form: a service with nothing wrong with it, unavailable because something underneath it was.

The part most reports left out

Because all three failed at roughly the same time, several outlets floated the theory that a shared cloud provider was behind it. Two facts stand against that theory: Microsoft denied responsibility, and none of the three companies published a shared root cause.

The distinction matters practically. If there were a confirmed common cause, the fix would be "pick a different cloud". With no confirmed common cause, the correct response is different: design on the assumption that any external service will be unavailable one day, regardless of why.

Why three at once is the interesting part

A few hours of downtime is not, by itself, a large event. Every service fails sometimes. What made this day different is correlation.

Plenty of teams believe that having two providers gives them a fallback. But if the primary and the alternate are both unavailable in the same window, that fallback existed on paper and not in practice. Redundancy is only worth what the correlation between failures allows — and that is something to measure before an incident, not during one.

Cursor makes the same point from another angle: dependency chains usually run deeper than the diagram shows. The service you depend on may itself depend on something you never wrote into your architecture.

What this means for a business in Karaj

Picture an online retailer in Karaj that has handed first-line customer replies to a conversational assistant, or a manufacturer in the Alborz industrial estates that summarises its daily production report through an external model. During a four-hour window like 3 September, the question is not why it broke. The question is what the customer experienced during those four hours.

There are three possible answers:

Nothing at all — because an alternate route or a simplified mode took over.
Noticeable delay — because requests queued and ran once service returned.
An error message — the worst outcome, because a customer cannot tell "our service is broken" from "our American vendor is broken". They only see that it did not work.

Choosing between those three is an architecture decision, made weeks before the incident. The same choice arises for an answering system, which we compare in language model or retrieval from your own knowledge.

Four things worth doing this week

1. A real second path, not a nominal one. For each critical capability, define a second model or provider — and more importantly, exercise it a few times a year. An untested fallback is an assumption, not a capability.

2. Queue instead of fail. Anything that is not immediate — summarisation, classification, report generation — should sit in a queue and run once service returns. The user sees latency rather than failure. It is the smallest change with the largest effect.

3. Graceful degradation. For real-time paths such as customer replies, define a simple no-model mode: an answer from your own knowledge base, a contact form, or a handover to a person. The online assistant on this site deliberately retrieves from the site's own content and depends on no external model, which is why a day like 3 September is a non-event for it.

4. Measure, don't guess. Record what share of requests failed and how long each incident lasted. Without that number, any conversation about "how resilient are we" is a matter of taste. The same measurement-first logic set out in AI governance in financial institutions applies here.

None of these four requires new technology. They are architecture decisions, usually deliverable within a few working days — the same ground covered in AI automation and business efficiency.

Frequently asked questions

How long did the 3 September 2026 outage last?

From roughly 7:43 am to 12:38 pm US Pacific — close to five hours until all three services were fully normal. Most ChatGPT users had service back after about an hour.

What was the shared cause?

None of the three companies published one. The theory about a shared cloud provider was denied by Microsoft. The only specific cause reported was a routing error on OpenAI's side.

Is having two providers enough?

Not necessarily. 3 September showed precisely that two services can be unavailable at the same time. What matters is the correlation between failures: two paths resting on the same infrastructure are one path with two names.

What is the smallest change with the biggest effect?

Turning non-urgent work into queued work. If summarisation, classification and reporting queue rather than call out directly, a multi-hour outage becomes latency the customer never notices.

How do I find out how exposed my business is?

List which customer-facing capabilities stop working without an external service, and write down what the user is shown in its absence. Every row where the answer is "an error message" is a concrete task for this month.

Qatreh is based at Alborz Science and Technology Park in Karaj and runs exactly this review on organisations' AI architecture:

AI consulting — reviewing dependencies and designing the alternate path
AI automation — queues, retries and simplified modes for automated processes
Enterprise chatbots — assistants grounded in your own knowledge base, with no external dependency
Computer vision and data science — on-site processing, where latency and availability matter
AI training and robotics — teaching teams to build systems that keep working when one service does not

The full picture of our work is at AI in Karaj.