Overlapping AI Outages Expose an Enterprise Resilience Gap
Four leading AI services had problems within the same few hours on September 3, 2026. OpenAI, Anthropic, and xAI confirmed service interruptions affecting ChatGPT, Claude, and Grok. Third-party monitoring also showed a shorter period of elevated failures for Google's Gemini API, although Google didn't post a corresponding incident on its public service health page.
There is no public evidence yet that one cloud, content delivery network, or routing failure caused all four events, which differentiates this incident impacting multiple disparate services. The outages may have been unrelated, or traffic shifting and automated retries may have increased pressure on alternative providers. Either way, the overlap exposed a continuity problem. AI services are becoming part of software development, customer service, analytics, security, and everyday office work, but many organizations still use them as if they were always available utilities.
What happened on September 3
- Claude experienced a broad partial outage. Anthropic began investigating elevated errors at 9:26 a.m. ET. The incident affected Claude's web application, API, Claude Code, and Claude Cowork across several models. Anthropic said it identified the cause but didn't disclose it. The main incident ended at 12:16 p.m., after almost three hours.
- Grok was unavailable across multiple channels. xAI reported problems beginning at 9:30 a.m. ET across the web, mobile apps, plugins, and API endpoints in two US regions. Traffic returned to normal shortly after 1 p.m. xAI hasn't published a root cause.
- ChatGPT and Codex returned elevated errors. OpenAI opened its incident at 10:43 a.m. ET, applied a mitigation 34 minutes later, and declared the issue resolved at 12:55 p.m. Fifteen ChatGPT components and four Codex components were listed as affected. OpenAI hasn't explained the underlying fault.
- Gemini's impact remains unconfirmed by Google. Ars Technica reported a sharp rise in user complaints and third-party API failures between about 10:45 and 11:15 a.m. ET. Google's public Gemini service history doesn't list a September 3 incident. AWS, Microsoft Azure, and Cloudflare also showed no broad outage that would explain all four events.
The current evidence supports a description of overlapping outages, not one common outage. Post-incident reports may change that assessment.
Past outages show how small faults become systemic events
- AWS S3, February 2017: One command had too much reach. An operator entered an incorrect value while removing servers during troubleshooting in the Northern Virginia region. The command removed more capacity than intended from two S3 subsystems, and recovery took more than four hours because those large systems hadn't been fully restarted in years. Other AWS services and many customer applications depended on S3. Even AWS' status dashboard administration console used it. Netflix is often included in retellings of this incident, but it remained available because its architecture was designed to tolerate component failures.
- Google Cloud and Cloudflare, June 2025: Different vendors shared one dependency. A quota policy update containing blank fields was copied globally within seconds. It triggered a software defect in Google Cloud's Service Control layer, causing many Google APIs to return errors for about three hours. Cloudflare then lost several services because Workers KV relied on third-party storage that failed during the Google Cloud incident. Cloudflare's core CDN stayed online, but Access, Gateway, WARP, Workers AI, Turnstile, and other services were impaired for two hours and 28 minutes. Buying from two vendors hadn't created two independent failure domains.
- AWS, October 2025: a DNS defect cascaded for more than 14 hours. A race condition in DynamoDB's automated DNS system produced an empty regional endpoint in the us-east-1 region. The initial database failure spread into EC2 instance launches, network load balancing, Lambda, identity services, contact center workloads, containers, and other AWS services. Backlogs and unstable health checks prolonged recovery after DynamoDB itself returned. Public-facing services including ChatGPT, Snapchat, and Amazon's own products, as well as Slack and Atlassian, experienced disruption. The incident showed that a regional fault can have global business impact when control services and customer applications converge on one region.
- Cloudflare, November 2025: A bad file was distributed everywhere. A database permission change caused Cloudflare's Bot Management feature file to double in size. The oversized file was sent throughout Cloudflare's network and caused traffic processing software to fail. The main impact lasted just over three hours, with full recovery taking almost six. A globally distributed platform provided little protection because the fault was also distributed globally.
- BGP failures can make healthy systems unreachable. In October 2021, a maintenance command disconnected Meta's global backbone. Its DNS servers then withdrew their Border Gateway Protocol routes, so the internet could no longer find Facebook, Instagram, or WhatsApp. Internal tools also failed, slowing recovery. A 2019 Verizon route leak showed the external version of the same risk, where incorrect routes from a small network were accepted and propagated by a major carrier, redirecting large volumes of traffic onto an unsuitable path.
Our take
The September 3 incidents don't prove that the four AI vendors share a single point of failure or one brittle infrastructure component. They do show that enterprises can lose several nominal alternatives at the same time. Model providers may use different data centers but still depend on common clouds, DNS services, CDNs, identity providers, transit networks, software libraries, and operational patterns. A multi-model strategy isn't resilient unless its alternatives fail independently.
AI also creates a possible secondary cascade. When one provider fails, gateways, applications, and users may redirect traffic to another. Uncontrolled retries and automatic failover can overload the remaining service just as it becomes the industry's backup. Long-running agents make the problem worse because a failed request may represent minutes of work, several tool calls, and partially completed changes rather than one lost chat response.
What IT leaders should be doing
- Classify AI workloads by business impact. Complete a business impact analysis (BIA) and separate optional productivity tools from customer-facing, operational, security, and regulated workloads. Set recovery time targets and define what each service should do when its model is unavailable. Some work can be queued, some can use a smaller model, and some must revert to a manual process.
- Map the full dependency chain. Record the model vendor, delivery cloud, region, CDN, DNS, identity provider, AI gateway, data store, connectors, and network path for each important use case. Don't count two model names as independent until the underlying dependencies and failure implications are understood.
- Qualify a secondary provider before an incident. Use a redundant, enterprise-controlled gateway or abstraction layer for critical workloads, but don't assume models are interchangeable. Test the backup against real prompts, structured outputs, tool calls, safety rules, latency, data-residency requirements, and cost. Keep credentials, capacity, and contracts active enough to make the switch practical.
- Design for controlled degradation. Use circuit breakers, short timeouts, request queues, rate limits, checkpoints, and unaltered (idempotent) operations. These controls prevent retry storms, preserve unfinished work, and allow jobs to resume without repeating external actions.
- Keep users and developers productive without the primary model. Maintain approved fallback assistants, standard templates, conventional search and documentation tools, and non-agent development workflows. Preserve drafts, prompts, tool results, and task state outside the model provider so work can continue or resume elsewhere.
- Monitor providers independently. Run synthetic tests against the exact models, regions, and API functions the organization uses. Alert on latency, error rates, malformed responses, and quota failures rather than waiting for a vendor status page. Keep incident communications and runbooks on infrastructure that doesn't share the affected dependency.
- Test the failure plan. Run game days that disable a model provider, cloud region, CDN, identity service, or network route. Measure failover time, output quality, queue recovery, cost, and the return to the primary provider. Service level agreements may provide credits, but they don't keep employees or applications working.