When ChatGPT, Claude, and Grok Fail Together

On 3 September 2026, ChatGPT and Codex, Claude, and Grok all experienced outages during the same US morning — 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 does not respond.

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.

Microsoft denied that an Azure outage was a shared cause, while Cloudflare said its services were operating normally. The reports cited here do not identify a common root cause.

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). One pattern to check is a single API key used to call one service synchronously, with no fallback. 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 event ran from late evening into the early morning in Indonesia.

Unattended jobs may fail before a person notices. Work potentially affected includes: 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. The effort to move them depends on how transaction state and dependencies are coupled.

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; set it from measured latency and the task’s user-facing deadline. A 20-to-30-second limit may suit a short chat task but can be too short for longer reasoning or tool use. 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 routing infrastructure can support failover too. 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, Gemini was an available secondary route, provided the integration had been tested.

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. A slower, simpler path can keep work moving when generated results are 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, retries may submit work twice. Local result caching does not guarantee provider billing deduplication if the first call completed but its response was lost. Check the provider’s idempotency support and record uncertain outcomes.

What should you check this week?

Search the code and record each dependency in a spreadsheet to start the inventory.

• 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", verify the timeout and error handling.
• 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. A system designed for missing responses can keep essential work moving during such incidents. Test that behaviour before the next outage.