When ChatGPT, Claude, and Grok Went Down at the Same Time

On the morning of September 3, 2026, millions of users worldwide started their workday with an error message. First Anthropic reported problems with Claude, shortly after OpenAI showed elevated error rates for ChatGPT and Codex, and almost at the same time outage reports piled up for xAI's Grok. For about five hours, three of the world's best-known AI systems didn't run reliably - for companies that had long since built these services into their daily operations, this wasn't an abstract tech-news event, but a tangible operational risk.

We're deliberately covering this incident here with some distance - as a wake-up call that reaches beyond the original headline. Because as brief as the media attention was, the real lesson of September 3 has by no means sunk in everywhere yet. Anyone who has integrated AI services into customer service, telephony, or internal processes today should understand exactly what happened that day - and what it means for their own operations.

For many companies, September 3 was the first moment when abstract risk considerations about AI providers turned into a very concrete, tangible outage. Until then, the quiet assumption in many places was that ChatGPT, Claude, or Grok, as established, multi-billion-dollar-funded services, are practically always available - comparable to electricity from an outlet. That assumption proved deceptive on September 3. And that's exactly why it's worth going through the incident systematically rather than filing it away as a brief footnote: what happened, why did it happen, and what follows from it for your own practice?

What actually happened on September 3

The timeline has since been documented independently by several sources, including Bloomberg, Axios, and The Register. Anthropic reported a "partial outage" around 9:23 a.m. Eastern Time (ET), causing disruptions to Claude Opus 5 as well as the Fable 5.1 and Mythos 5.1 model versions. The fix took effect there around 12:16 p.m. ET. Almost in parallel, starting around 10:43 a.m. ET, OpenAI reported "elevated errors across ChatGPT and Codex." Outage reports also piled up for xAI's Grok at the same time. In total, it took until around 12:38 p.m. Pacific Time for ChatGPT, Claude, and Grok to be fully back up - adding up to roughly five hours of disruption in total, not a matter of minutes.

On the user-reporting portal Downdetector, the scale was clearly visible: at its peak, around 40,000 users reported problems with OpenAI services, about 1,500 for Claude, and a similar order of magnitude for Grok. There was also a noticeable rise in reports for Google Gemini - though with an important caveat we'll get to shortly.

Transparency matters to us here: the event we're writing about did demonstrably take place on September 3. Several reputable outlets - Bloomberg, Axios, Forbes, The Register, and Computerworld - consistently date the incident to that day. We're deliberately picking it up here because the lessons from it don't lose relevance with some distance - if anything, they become clearer.

It's also worth being precise about the number of affected providers. Clearly documented and confirmed by multiple sources are disruptions at exactly three companies: OpenAI (ChatGPT, Codex), Anthropic (Claude), and xAI (Grok). Google Gemini showed elevated outage reports according to Downdetector, but Google itself did not publish an official incident entry on its status page. Whether Gemini was "officially" affected as well thus remains unclear - a fourth, uncertain case that should be distinguished from the three clearly documented outages. And: none of the three affected providers has confirmed an attack or a coordinated cause. Trade media largely attribute the clustering to shared cloud infrastructure dependency, not to cybercrime.

The one shared weak point: cloud infrastructure

Secondary reports name an outage in the Microsoft Azure East US region as the likely cause. It's important to be clear here: this cause comes from trade-media reporting and was not confirmed in an official, primary-source-verified post-mortem by Microsoft, OpenAI, or Anthropic. It's regarded as the most plausible, but not the proven, explanation.

Still, it's worth a second look at this exact point, because it reveals a structural problem that goes beyond the specific incident. Anthropic officially runs a multi-cloud strategy across AWS, Google Cloud, and Azure. Yet a relevant share of Claude's production traffic reportedly still ran via Azure-linked paths. In other words: even a provider that on paper uses multiple cloud providers can remain vulnerable at a single point in the background.

A single regional infrastructure failure can hit several seemingly independent AI platforms at once. Companies that had embedded ChatGPT, Claude, or Grok into business-critical workflows without a documented continuity plan experienced immediate production outages.

That's how Sandy Carter sums up the central lesson for executives in her Forbes analysis of September 5. And this is exactly where it hurts most for the Mittelstand: the assumption "I use multiple providers, so I'm covered" falls short if those providers share the same cloud infrastructure in the background. Multi-provider is no substitute for multi-infrastructure.

Why this is no longer an academic question for the German Mittelstand

You could dismiss this incident as a problem for big tech corporations - if not for the speed at which AI is already being used productively in German companies. According to Bitkom, 41 percent of German companies now actively use AI, up from just 20 percent in 2024. A further 32 percent are planning to adopt it. The main areas: 71 percent use AI for text and translation, 53 percent for marketing and communication, 42 percent in customer service, and 31 percent for data analysis.

It's precisely the 42 percent customer-service share that makes the September 3 incident concrete. Generative AI can cover 70 to 90 percent of support tickets in this area - but only if the knowledge base and human fallback are cleanly designed. Without these prerequisites, coverage drops to 30 to 40 percent. This range isn't a minor detail; it's the actual crux of the matter: the fallback question determines whether an AI outage is a shrug or an emergency for your company.

Anyone who, for example, has switched their phone-based customer service entirely to an AI assistant without a practiced human fallback layer may have been left without a working channel for five hours on September 3. Five hours in which customers couldn't get through, requests went unanswered, and internal processes stalled. That's the difference between a tool that makes work easier and a dependency that becomes a single point of failure.

What downtime actually costs - and what that means for SMEs

Downtime cost figures help gauge the urgency - though with an important caveat: the following figures come from a general Splunk/Oxford Economics study on IT downtime overall, not specifically about this AI outage and not specific to the German Mittelstand. They still provide a useful order of magnitude: on average, downtime costs around $15,000 per minute, and Global 2000 companies collectively rack up about $600 billion a year in downtime costs - up 50 percent in two years. Per organization, that works out to an average of around $300 million a year, or more than $900,000 per hour of outage.

These orders of magnitude come from the world of large corporations and can't be directly transferred to a mid-sized business. But the direction is clear: the more strongly a company integrates AI-supported processes into its operations, the more an outage of those processes affects revenue, customer loyalty, and internal workflows - proportionally smaller than for a global corporation, but just as real for the individual business. The accompanying Splunk study also shows: around half of the organizations surveyed had already experienced downtime due to faulty AI automation or model drift, and nearly a third due to bugs from AI embedded in production systems. You could call this a "reliability paradox": the more aggressively companies deploy AI to reduce operational risk, the more a new, hard-to-predict risk category emerges.

From the multi-provider illusion to real resilience

Computerworld put it succinctly in its headline on the incident: ChatGPT, Claude, and Grok went down at the same time - companies need a backup plan. The accompanying analysis from the AI Governance Institute speaks in this context of "AI concentration risk": the incident is being read industry-wide as evidence that critical infrastructure is dangerously concentrated among a few, cloud-dependent AI providers.

What does that concretely mean for your business? First: actively ask which cloud region or hyperscaler your AI provider actually runs on, rather than relying solely on the "multi-cloud" label. Second: for every AI-supported, business-critical process - telephony, customer service, order intake - there should be a documented, practiced manual fallback plan. According to the Forbes analysis, exactly the companies that didn't have such a plan experienced immediate production disruptions during the outage. Third: deliberate triage is worthwhile. Which processes can run fully automated without a fallback layer because an outage there is tolerable? And which absolutely need an escalation step to a human because real customer relationships or revenue are at stake?

A look at Info-Tech's own analysis, "Overlapping AI Outages Expose an Enterprise Resilience Gap," confirms this picture: the gap rarely lies in the AI technology itself, but in the missing continuity planning around it. Anyone running an agent for customer service but who has never rehearsed what happens if that agent is unreachable for five hours has built in an operational risk that only becomes visible in an actual emergency.

Connected to this is an aspect that's easily overlooked amid the excitement over technical causes: clear internal and external communication processes for outage periods should be defined in advance, not improvised during the disruption itself. Who knows how customers are informed if the AI phone assistant fails? Who takes over incoming requests in the meantime? How long is a disruption allowed to last before it gets escalated to management? The five-hour incident of September 3 shows that outages can last several hours even at established major providers - not just minutes, as you might instinctively assume. A company that has no plan for this loses valuable time exactly when it matters most.

This planning doesn't have to be complicated. Often a simple checklist is enough: who gets informed, which channel steps in, which customers get contacted proactively, when does an outage count as "critical enough" to escalate to management. It also helps to assign fixed responsibilities in advance, rather than figuring out who's actually in charge only once the emergency hits. The difference between a company that gets through a five-hour disruption calmly and one that descends into chaos rarely comes down to the technology - it comes down to whether this plan already existed beforehand or had to be improvised during the outage. That difference ultimately decides whether customers perceive a disruption as a minor annoyance or a breach of trust.

What you should concretely take away from September 3

The incident of September 3, 2026, is no reason to stop using AI agents in your own business - the usage and growth figures in German companies show that this technology is establishing itself regardless. But it is a good occasion to honestly answer three questions. Do you know which cloud infrastructure actually sits behind your AI provider? Do you have a documented human fallback for every business-critical, AI-supported process? And is there an agreed communication plan for the case that a disruption lasts several hours?

Anyone who can answer these three questions with yes has already drawn the right lesson from the outage of the three big providers. Anyone who can't shouldn't find that out only at the next outage. Because one thing September 3 showed: the question is no longer whether such an incident will happen again, but when - and how well prepared your company will be by then.

The right balance matters here. It's not about giving up productive AI use out of fear of outages - given the adoption figures in the German Mittelstand, that would be a competitive disadvantage anyway. It's about embedding AI agents into existing workflows in such a way that a provider disruption becomes a manageable nuisance rather than a multi-hour standstill of business-critical processes. That difference - between unreflective dependency and deliberately designed resilience - determines whether the next big AI outage catches your company off guard or barely affects it at all. September 3, 2026, was, in that sense, not an outlier but a dry run for how good your own preparation really is - and a good time to catch up on that preparation now, instead of being caught off guard again at the next incident.