When ChatGPT, Claude, and Grok Fail Together

When ChatGPT, Claude, and Grok Fail Together

On 3 September 2026, ChatGPT and Codex, Claude, and Grok all failed inside the same morning US time — roughly 21:43 WIB onward for Indonesia. Each vendor named a different cause. If your product routes work through one AI API, the answer is not a better vendor. It is a path that still works when the API answers nothing.

What actually happened on 3 September 2026?

Three separate incidents landed inside the same few hours.

OpenAI attributed its outage to a routing error starting around 7:43 a.m. PT, which made ChatGPT and Codex unavailable for some users across platforms. Anthropic reported a partial outage across Claude.ai, Claude Code, and the Claude API, and described it as an infrastructure issue; its Opus models were the last to return to baseline. xAI pointed at its Memphis compute centre. The Register logged all three on 3 September 2026, and 9to5Google tracked recovery to around 12:38 p.m. PT the same day. Downdetector reports against OpenAI alone ran into the tens of thousands, per Axios' coverage that day.

Two details matter more than the timeline. Gemini stayed up. And Cursor, the AI coding tool, degraded anyway — because it calls the models that were down.

The shared-cause theory did not survive the day. All three vendors run significant workloads on Microsoft Azure, so Azure was the obvious suspect. Microsoft said that was not the case, Cloudflare said its own services were operating normally, and no provider has published a common root cause since.

Why did three independent vendors fail at once?

On the public record, they didn't share a cause. Three separate faults, one window. That is either a bad coincidence or a market concentrated enough that bad coincidences stop being rare.

From the buyer's seat the distinction is academic. Your feature was down. The post-incident blog you eventually read will not refund the four hours.

This is ordinary concentration risk wearing a new hat, and Indonesian businesses are walking into it fast. AWS and Strand Partners put AI adoption among Indonesian companies at 40% in their Unlocking Indonesia's AI Potential 2026 study, up from 25% a year earlier (reported 7 August 2026). Most of that adoption is a single API key pasted into a single service, called synchronously, with no plan B. It is the same shape of dependency we already know how to find in any other single point of failure.

What broke for Indonesian businesses at 21:43 WIB?

The timing is the local story. 7:43 a.m. PT is 21:43 WIB. Recovery at 12:38 p.m. PT is 02:38 WIB the next morning. The whole event happened while Indonesia was asleep.

Nobody was watching, so nothing got caught by a human. What suffered was the unattended work: overnight document extraction, nightly report generation, chat auto-replies to customers in other timezones, classification jobs feeding the next morning's dashboard.

Three failure shapes show up over and over in that scenario:

• The silent drop. A job calls the API, gets a 500, has no retry, and logs a warning nobody reads. The work simply never happened. Someone notices on Monday when a report is short by 400 rows.
• The retry storm. The opposite failure. A job retries immediately and forever against a dead endpoint, burns its whole runtime window, and finishes nothing while looking busy in the logs.
• The hung request. A customer-facing endpoint calls the model with no timeout. Requests pile up, connections exhaust, and a feature outage becomes a whole-app outage.

The third one is the expensive one. An AI feature being unavailable is annoying. An AI feature taking down checkout is a different conversation with the client.

Which parts of your system should never wait for an AI call?

One rule covers most of it: an AI call may never sit inside a path that must complete. Payment capture, door access, order submission, alarm dispatch, attendance recording. If the transaction cannot finish without a model responding, you have built a business process on somebody else's uptime.

Sort every AI call you make into three tiers.

That third row is not a joke. In most systems I review, the blocking tier turns out to hold one or two calls that got there by accident — a validation step someone made "smart", an auto-categoriser that the save button waits on. Moving them is usually an afternoon of work.

How do you build a fallback that actually works?

Five pieces, in the order I would add them.

1. Queue instead of calling inline. Accept the user's input, write it somewhere durable, return immediately, and let a background worker do the AI part. This single change converts most outages from an incident into a delay. It is the same pattern that makes field apps survive bad signal — take the work first, sync later.

2. Timeout, then stop trying. Every AI call gets a hard timeout; 20 to 30 seconds is generous for a chat completion. Pair it with a circuit breaker — a switch that stops calling a service after repeated failures, so one dead dependency cannot drag the rest of the system down with it. Retries need backoff and jitter, a small random delay added to each retry, so your workers don't all hammer the endpoint at the same instant when it recovers.

3. A second provider, kept warm. Routing between models is something you probably already want for cost reasons, and the plumbing is the same: route by task, cap by day, and the failover path comes almost free. The catch is that an untested fallback is not a fallback. Send a slice of real traffic to the secondary every week. On 3 September, a team with Gemini wired as secondary would have stayed up.

4. A non-AI path underneath. Sometimes both providers are unreachable, or the whole class of service is having a bad day. Decide in advance what the degraded version looks like: a template reply instead of a generated one, rule-based routing instead of classification, a human review queue instead of auto-approval. Slower and dumber beats unavailable.

5. Idempotency on anything you pay for. Idempotency means sending the same request twice produces one result instead of two. Attach a key generated from the work item, not from the HTTP request, and store the first successful response against it. Without this, a retry storm during an outage bills you twice for generations you already have.

What should you check this week?

Ten minutes with a grep and a spreadsheet gets you most of the way.

• List every place your code calls an AI API. Include the ones inside cron jobs and webhook handlers, which is where the forgotten ones live.
• For each: what happens after 30 seconds of no response? If the answer is "I'm not sure", that call has no timeout.
• Are retries bounded, and do they back off? An unbounded retry loop against a dead endpoint is a self-inflicted outage.
• On failure, is the user's input preserved or lost? Losing the input is worse than showing an error.
• Is anyone alerted at 22:00 WIB, and does the alert distinguish "the vendor is down" from "our code is broken"? Those need different responses.
• Read the uptime commitment in your provider's terms, then read the one you gave your client. If yours is stricter than theirs, you have promised something you do not control.

That last point catches people. A 99.9% commitment sounds safe until you notice you are reselling somebody else's 99.5% and absorbing the difference yourself.

The part that doesn't change

AI vendors will keep having outages. So do payment gateways, so does the electricity, so does the road to the office. The design question was never whether the dependency is reliable. It is what your system does in the hours it isn't.

Three providers, three causes, one morning. The teams that barely noticed on 4 September were not the ones who picked the right vendor. They were the ones who had already decided what happens when the answer never comes.