The AI Vendor Outage Playbook: What to Do When ChatGPT, Claude, and Grok Go Down Together

What happened. On the morning of September 3, 2026, the three AI vendors most agencies build on went down at the same time: OpenAI's ChatGPT and Codex, Anthropic's Claude (Claude.ai, Claude Code, Claude Cowork, and the Claude API), and xAI's Grok (Axios; DataCenterDynamics; 9to5Google; CNET; Gizmodo). User reports started around 9:00–9:30 a.m. ET; by mid-morning all three vendors had active status-page incidents; and by early afternoon everything was nominally back to normal. No single common cause was ever confirmed. The 09-03-2026 simultaneous outage is now the reference case for why AI API reliability has to be designed, not assumed — and why a single backup vendor is not a backup plan.

This page is the AI vendor outage playbook for agencies and anyone running production workloads on AI APIs: a short incident recap, then concrete, copy-paste-able actions — monitoring, fallback models, multi-vendor routing, timeout/retry/circuit-breaker configuration, SLA remedies, escalation and client communication, and a local-model escape hatch.

Incident recap: the AI outage of September 3, 2026

Timing matters because it exposes the difference between user impact and official notices — the same gap your monitoring has to cover:

• ~9:00–9:30 a.m. ET — Downdetector-style user reports spike for ChatGPT, Claude, and Grok, before most official status notices (CNET; Gizmodo).
• 9:26 a.m. ET (13:26 UTC) — Anthropic status: Investigating elevated errors on Claude models; cause identified at 9:41 a.m. ET; affected list at 9:50 a.m. ET spans Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, and Opus 4.6 (status.claude.com).
• 10:43 a.m. ET (7:43 a.m. PT) — OpenAI's stated start: "A routing error starting around 7:43am PT … made ChatGPT and Codex unavailable for some users across platforms" — a solution was implemented by 11:17 a.m. ET (OpenAI update via Gizmodo; BleepingComputer).
• Through the late morning — Grok showed "this model is overloaded right now. Please try again shortly or pick a different model"; xAI logged incident INC25664c15 with no root cause given (DataCenterDynamics; 9to5Google).
• 12:16 p.m. ET (16:16 UTC) — Anthropic logged impact as ended; Opus 4.8 and Opus 5 were the last models to recover (status.claude.com; Gizmodo).
• 3:38 p.m. ET (12:38 p.m. PT) — 9to5Google update: "All services are back to normal across ChatGPT, Claude, and Grok."
• 4:22 p.m. ET — hours after the outage, OpenAI released GPT-6 Astra — timing that fed launch-day speculation but was never tied to the outage as a cause (Gizmodo; see our GPT-6 Astra vs the field comparison).

Gemini caveat: Google's Gemini saw user reports and some developer/API issues — including problems with recently created API keys — but never declared a confirmed outage; sources disagree on how much it was affected (Axios; 9to5Google vs CNET; Gizmodo; Economic Times). Treat Gemini as "reported issues, no confirmed outage" on this date.

The lesson levelsio proved live: one backup vendor is not enough

Pieter Levels (@levelsio) runs real products on AI APIs, and he documented the failure mode in real time through the outage morning. First: "xAI's API is down!" Then, after switching: "I switched my API to Claude now but now Claude also went down!" (X status 2095517218217902313), then "If both @xAI and @claudeai are down — does that mean the Colossus GPU farm is down?" (X status 2095522299722019002), and finally "No way now ChatGPT is down too?!!!" (levelsio via twiscan mirror).

The sequence is the whole lesson: he had a fallback, used it correctly, and the fallback was down too. As one machine-translated recap of his morning put it, "a backup key is not insurance… when outages coincide in time, switching gives nothing" (vibecoding.ru). Two structural reasons this happens:

• Shared failure modes. The major vendors run on overlapping infrastructure — reporters noted all three use Microsoft Azure for cloud services, and Azure was having its own problems that morning. "Same cloud, three vendors" is closer to one big single point of failure than to three independent ones (Axios; CNET). (No common cause was confirmed — OpenAI said routing error, Anthropic said infrastructure issue — but the architecture makes correlation plausible.)
• Dependency chains. Downstream products fail when their model vendors fail: Cursor confirmed an outage because of the Grok and Claude outages (9to5Google). If your agency's product depends on an AI vendor, you are the next Cursor in that chain unless you build redundancy in front of it.

The AI vendor outage playbook

Each section below is a concrete action with the settings and thresholds to start from. Work the list in order — monitoring first, because you cannot run the other steps blind.

1. Monitor vendor status pages and your own API error rates

Status pages are necessary but not sufficient: on Sept 3, user reports spiked around 9:00–9:30 a.m. ET while official vendor notices landed later — and Anthropic's Claude API incident ran on a model-level status page most dashboards don't read (CNET; Gizmodo; status.claude.com). Monitor both layers:

• Vendor status pages + their JSON/RSS endpoints: status.openai.com, status.claude.com, and status.x.ai all publish machine-readable feeds. Poll them every 1–2 minutes, or subscribe to their status-page notifications; alert on any non-operational component, and map each component to the workloads that use it (Claude API ≠ claude.ai ≠ Claude Code).
• Your own traffic is the earlier signal: track API error rate (5xx + 429 as a share of requests), p95/p99 latency, and timeout rate per vendor per model, over a 5-minute window. Alert when error rate exceeds 5% for 5 consecutive minutes or latency p99 doubles its 7-day baseline for 10 minutes. On Sept 3 the first symptom your app would have seen was timeouts and 5xx, before any status-page update.
• Synthetic checks: one request per minute per vendor from your own infrastructure, asserted on a 200 + sane latency. Synthetic checks catch "up but degraded" states that error-rate-only monitors miss.
• Do not alert humans on every blip: page a human only when your automated mitigation (below) has already failed for N minutes — otherwise the runbook becomes noise and nobody pages out.

2. Configure fallback models and providers before you need them

• Per-workload fallback table: for every workload, name a primary and at least one fallback (e.g., Claude API → GPT-5.6/GPT-6 Astra family → Gemini; Grok → GPT family → Claude; any coding agent → Gemini 3.8 Flash or an open-weight model). Store this in your routing config, not in someone's head.
• Fallbacks must be tested, not just configured: run the same prompts through the fallback monthly and diff output quality on your own task set — model quality differences are why agencies route in the first place (see AI agent workload routing).
• Provider-agnostic plumbing: keep prompts, tool schemas, and output contracts in a neutral format; use an OpenAI-compatible adapter or a gateway (LiteLLM-class, OpenRouter, or a small in-house shim) so a fallback switch is a config change, not a rewrite. OpenRouter's per-model pages even surface a "higher uptime with 2 providers" note — that is the same multi-provider idea applied to a single key.
• Do not fall back to the same vendor's different endpoint: ChatGPT web down ≠ API down, but when the API incident is infrastructure-wide (as Anthropic's was), a different model on the same API is not a fallback. The fallback must be a different provider or a different failure domain.

3. Implement multi-vendor routing and failover across independent stacks

• Route by workload with health weights: send each request to the primary vendor while it is healthy; on 5xx/429/timeout past your retry budget, route to the fallback. Health-based weighting (e.g., 80/20 primary/fallback when both are up) keeps the fallback warm so the first failover is not a cold start.
• Make "independent" mean independent: different model families and different cloud footprints. Because OpenAI, Anthropic, and xAI overlap on Azure, an OpenAI→Anthropic failover can still die with a shared-cloud event; add a provider on a different cloud (Google's Gemini, or a self-hosted model) to your critical path (Axios; CNET).
• Scope failover per client deliverable: an agency running 30 clients on one API key is 30 Cursors. Decide which client workloads are critical enough for multi-vendor routing and quote the redundancy cost into those retainers; routine batch work can stay single-vendor with a slower manual fallback.
• Log the route: record which vendor served each request and why (primary vs failover). You will need that trail for client reporting and for the SLA-credit evidence in step 5.

4. Set timeout, retry, and circuit-breaker behavior

• Timeouts: set per-call timeouts at 30–60s for chat-style calls (streaming first-token < 10s is a good alert line) and 2–5 minutes for long batch jobs — not "no timeout." A hung call on a degraded vendor will otherwise pile up.
• Retries: exponential backoff with jitter, starting at 1s and doubling to a cap of ~30s, for a maximum of 3–5 attempts, retrying only on 5xx, 429, and network errors — never on 4xx. Add jitter (±20%) so recovery doesn't create a thundering herd that re-breaks the vendor.
• Circuit breakers, per vendor and per model: open the circuit after 5 consecutive failures (or 50% errors over a 60s window), trip all traffic to the fallback for a cooldown of 30–60s, then half-open and probe with a small share of traffic before closing. Separate breakers per vendor mean a Grok outage doesn't take down your Claude lane.
• Timeouts and retries are not the whole answer: on Sept 3, levelsio's retries would have failed too — his fallback provider was down. Circuit breakers route to the fallback, but step 3 is what makes the fallback actually survive a correlated outage.
• Test the failure path: run a chaos drill that force-fails your primary vendor in staging and confirm traffic shifts within your target RTO (start with 5 minutes).

5. Know your SLA remedies and credit processes

• Read the actual SLA, not the marketing page: most AI vendor SLAs are monthly-uptime commitments (typically 99.5–99.9%) with service credits as the remedy — not incident-by-incident refunds, and usually not covering degraded-but-not-down periods. Anthropic's own 90-day window captured on Sept 3, 2026 showed the Claude API at 99.5% — about four hours of allowed degradation per year under that arithmetic (status.claude.com). A multi-hour API incident like Sept 3 may not breach a monthly SLA at all.
• Know the filing path before the incident: enterprise agreement credits go through your account team; self-serve credits usually start from the status page or a support ticket. Ask now: who files, what evidence do they need, and what is the deadline (often 30 days)?
• Document impact as it happens: timestamped error logs, request counts, incident IDs (e.g., Grok's INC25664c15, Anthropic's Sep 3 status incident), and status-page screenshots are the evidence package. Store it the same day — "we were affected" is much easier to prove while it is happening.
• Factor SLA gaps into your own client terms: if the vendor's SLA allows hours of downtime, your agency SOW should not promise 100% availability either — mirror the vendor credit structure and define what the client gets if a vendor incident hits their deliverable.

6. Prepare internal escalation and client communication templates

• Internal escalation tree: define who is on call, in what order, and what triggers each level (error-rate alert → automated failover engaged → failover also failing → incident commander + client notice). Name the incident commander per client account before the incident.
• Pre-drafted client templates in three tiers — write them now, fill the blanks during the incident:
  • Monitoring notice (only for critical accounts): "We're seeing elevated error rates from [vendor] affecting [service]. Our automated failover to [fallback] is active. No action needed from you; we'll update by [time]."
  • Status update: "[Vendor] has declared an incident (ref [ID]) affecting [surfaces]. Impact on your [deliverable]: [none/partial/degraded]. Estimated recovery: [vendor estimate]. We are running on [fallback]."
  • Post-incident recap: "What happened, what we did, how long impact lasted, what [vendor] credits we claimed, and what we changed so it doesn't recur." Send the recap within 48 hours — it is the difference between a client who is annoyed and a client who trusts your operations.
• Tell clients the truth about vendor risk up front: the SOW or onboarding doc should say you run on best-in-class AI vendors, that no AI API is 100% available, and that you mitigate with monitoring, fallbacks, and failover. A client who learns about AI outages from the news is a client who will blame you; a client who was briefed in advance is a client who watches you handle it.

7. Keep a local or self-hosted model escape hatch for critical workloads

• The only escape hatch with no vendor status page: on Sept 3, the hosted options were down simultaneously, and the workloads that kept running were on infrastructure outside the affected vendors. During the outage, levelsio noted in replies that Claude was failing on his laptop but working on his server — his read: "It seems Claude prioritizes servers when it goes down? … Another reason to run it on your VPS" (anecdotal, and speculation about Anthropic's behavior — treat it as color, not policy).
• What to self-host: an open-weight model (Qwen, GLM, Llama-class) behind vLLM or Ollama, sized for your genuinely critical workloads — client-facing classification, PII-safe extraction, form filling, anything where "vendor down" is unacceptable. This is insurance for critical workloads, not a replacement for frontier models; see what open-weight models do to margins for the honest cost picture.
• Keep it warm: run a small percentage of low-risk traffic (or a nightly batch) through the local model so the escape hatch is proven and the weights are current. An untested local stack is a second outage waiting to happen.

8. Run the drill and do the post-incident review

• Quarterly tabletop: "All three major vendors are down for two hours. Client X's deliverable is due today." Walk it end to end — who pages whom, which workloads shift where, what the client email says, when you invoke the local model.
• After every real incident, write the 4-up: what happened (vendor timeline vs your timeline), what your monitoring caught early and late, how long until mitigation worked, and one configuration change to make now. The Sept 3 play is already written for you: it is the incident recap at the top of this page.

Frequently asked questions

Sources

• Axios — "Widespread AI outage underway" (Sept 3, 2026): axios.com
• DataCenterDynamics — "ChatGPT, Claude, and Grok hit by simultaneous outages" (Sept 3, 2026): datacenterdynamics.com
• CNET — "AI's Very Bad Morning" (Sept 3, 2026): cnet.com
• 9to5Google — "ChatGPT, Claude, and Grok down" (confirmed outages, Sept 3, 2026): 9to5google.com
• Gizmodo — "All the Major AI Chatbots Are Experiencing Outages Right Now" (Sept 3, 2026): gizmodo.com
• Anthropic status — status.claude.com, Sept 3, 2026 incident history ("Elevated errors for multiple models"; 90-day uptime windows captured Sept 3, 2026): status.claude.com
• BleepingComputer — "OpenAI confirms ChatGPT is down" (Sept 3, 2026): bleepingcomputer.com
• levelsio on X — outage-morning posts (Sept 3, 2026): x.com/levelsio/status/2095517218217902313 · x.com/levelsio/status/2095522299722019002 · text mirror: twiscan.com
• vibecoding.ru — "Switching to backup API didn't help" (Sept 3, 2026 recap of levelsio's sequence): vibecoding.ru
• Gizmodo — "OpenAI Claims We're in the 'AGI Era' With Release of GPT-6 Astra" (Sept 3, 2026, 4:22 p.m. ET): gizmodo.com

Accuracy note: Timeline and vendor language verified September 3, 2026 against the sources above. Gemini was reported as affected by some outlets (CNET; Gizmodo) but never declared a confirmed outage by Google; 9to5Google and Axios said Gemini appeared unaffected or unreported at the time, and Economic Times narrowed reports to developer/API issues with recently created keys — this page says "reported issues, no confirmed outage." No common cause for the simultaneous outage was confirmed; the Azure overlap is reported as a hypothesis (Axios; CNET), not a finding. The "Colossus GPU farm" question is levelsio's speculation and is not presented as fact. levelsio's post text is quoted verbatim from mirrors and X status pages; exact posting timestamps were not independently verified, so this page says only "through the outage morning." The 99.5% Claude API uptime figure is Anthropic's own 90-day status-page number captured on Sept 3, 2026 and is not a warranty. Uptime thresholds and circuit-breaker numbers in the playbook are starting points for your own engineering review, not guarantees. GPT-6 Astra was released hours after the outage; no source tied the outage to the Astra rollout. Re-verify vendor status before acting on any of this.