ChatGPT, Claude, Grok outages: achieving multi-provider AI high availability in a capacity-constrained world

Summary

On September 3, 2026, three of the most popular AI providers (OpenAI, Anthropic, and xAI) all returned elevated errors from their hosted models. That covered ChatGPT, Claude, and Grok directly, plus every product built on their APIs, such as Cursor. Depending on which tool you had open, a Claude Code session might hang while trying to reach Anthropic's servers, or ChatGPT might return an "unavailable" error.

For Anthropic and xAI, the root cause was a hardware failure in Colossus, a large data center in Memphis. Their incidents were opened within 4 minutes of each other. SpaceX, which owns xAI, owns Colossus but rented nearly all of its capacity to Anthropic back in May. At the time, xAI was only using 11% of the data center's 220,000 Nvidia GPUs, according to actuia, so it gave Anthropic exclusive access for Claude inference to cover its losses.

OpenAI's incident started about 1 hour 15 minutes after Anthropic's and xAI's. According to its published RCA, a routing configuration change stopped requests from reaching its services, the kind of thing a misconfigured API gateway would do. Requests were dropped, and even after the fix, the returning traffic from retries and normal load overwhelmed the services and prolonged recovery.

There's no smoking gun, but many sources have suggested that model routers like OpenRouter played a part in OpenAI's trouble. These services route inference requests across providers and models, so when Anthropic and xAI went down, OpenAI may have absorbed their traffic. OpenAI attributes the outage to a configuration change it deployed, but that change may have gone out as traffic climbed, to route the extra load differently.

What's the big deal?

My biggest takeaway wasn't that these providers went down. That happens often, given how popular they are and the scaling challenges they face.

The bigger issue is how much organizations rely on these providers, and the reliability they expect from using several of them. Even if you used all three, you would still have had an outage: two of them failed for the same reason (they share a data center), and the third may have failed because the other two did.

The closest analogy is a multi-cloud strategy. Many large companies don't depend on a single cloud or data center because it is too risky. They spread their services across several clouds and data centers to avoid a single point of failure, which also lets them reroute traffic quickly.

But what do you do when none of the major providers are up? As companies rely more and more on AI for operations (automated workflows, developer productivity, chatbots, and so on), they need to be sure some option is always available to them.

What should I take away from this?

This brings me to my main point: open-source models and self-hosted inference will be crucial. OpenAI, Anthropic, and xAI all serve proprietary models that force customers onto their hosted services. But there are many very good open-source models today, ranging from tens of billions of parameters to trillions. Hosting them in on-prem data centers or on cloud VMs gives a company something to fall back to during a total outage like the one on September 3.

That doesn't mean relying on open-source models exclusively. The AI labs build models at the cutting edge, and those are often the most powerful ones available for defending against cyber attacks and finding software vulnerabilities. Still, for any organization that can't afford hours of inference downtime, a prudent strategy includes self-hosted open-source models. They can sit idle and be spun up within minutes on VMs, serve a share of traffic continuously as part of the routing strategy, or something in between.

Timeline of the Outage

Elapsed times are measured from the earliest public sign of impact at 12:45 UTC. I use the first customer reports rather than each company's own status updates as the start, because that is when users started to feel it.

The OpenAI and xAI resolution times are derived from the gaps between their updates rather than published directly.

Assessment

Time-to-detect (TTD)Anthropic 🟡 4 / 10xAI 🟢 9 / 10OpenAI 🟢 10 / 10

Anthropic

A post on X by statusisdown.com at 12:45 UTC came 41 minutes before Anthropic's first status update. That data comes from real-time outage reports by customers themselves, not from the company's own data or communication channels.

That is far beyond the target of 5 minutes or less. It isn't clear when Anthropic actually detected the issue, though. It could have known internally well before the status page went up 41 minutes later, so its true TTD was probably under 41 minutes. Anthropic published no post-incident review to settle it, so I'm giving it a 4.

xAI

Users reported Grok issues at 13:29 UTC, one minute before xAI opened its status page. That's a much better story. It gets a 9 rather than a 10 because Claude and Grok shared a root cause (the Colossus outage), so Grok users may well have been affected earlier. I just don't have evidence of that yet.

OpenAI

The first statusisdown.com reports for OpenAI arrived around 15:14 UTC, 29 minutes after OpenAI's status page went up at 14:43 UTC to say ChatGPT and Codex were returning elevated errors. OpenAI declared before customers noticed, which earns a 10.

One caveat: OpenAI says a routing configuration change caused this. For deployment-related incidents I expect especially fast detection, because the team can measure impact as the change rolls out.

Detection sourceAnthropic 🟢 7 / 10xAI 🟢 8 / 10OpenAI 🟢 10 / 10

Anthropic

Users were clearly reporting problems at least 41 minutes before Anthropic said anything. Anthropic's previous blog posts strongly suggest it uses SLI/SLO-based alerting, which lags behind what users experience until the burn-rate thresholds are crossed.

For an impact this large, customer reports and internal alerts probably arrived close together, so I'm giving this a 7.

xAI

xAI scores a little higher than Anthropic. The root cause was the same, but only one minute separated the first user reports from xAI's first status update. That gets an 8.

OpenAI

OpenAI gets a 10: it appears to have known about the incident and declared it before any reports, automated or manual, showed up on X.

Status page updatesAnthropic 🔴 2 / 10xAI 🔴 1 / 10OpenAI 🟢 8 / 10

Anthropic

The status page communication was quite poor. As covered under detection, the first update came nearly an hour after the first user reports.

Early on, updates came every 10-15 minutes, which is good. They focused on impact (which models were affected) and noted that the root cause had been identified. After that, updates slowed to every 30-60 minutes despite the level of impact. Some said only "We are continuing to work on a fix for this issue", with no other detail and no hint of when the next update would come.

I'd like to see more detail on the root cause, and at least an expected time for the next update, even when there's nothing new to report.

xAI

This was an abysmal status page. It opened promptly, then went silent for over 3.5 hours until traffic was healthy again, and that closing post was the only other update. There was no expected time for the next update, no explanation of impact, and no word that the root cause or a fix had been found. Apart from opening it on time, this is about as bad as it gets.

OpenAI

OpenAI handled its status page best:

• It opened the page before users started reporting issues.
• It listed the affected services.
• It said a mitigation had been applied and it was monitoring.
• 1.5 hours later, it confirmed full resolution, with steps mobile users might need to take to recover.
• Within 48 hours, it published an RCA write-up and attached it to the incident.

It gets an 8 rather than higher because updates could have been more frequent, say every 15 minutes. Overall, though, I like how it handled this.

Time-to-mitigate (TTM)Anthropic 🔴 3 / 10xAI 🔴 2 / 10OpenAI 🟢 8 / 10

Anthropic

The first mitigation came at 15:25 UTC, about 2 hours 40 minutes after the first user reports on statusisdown.com. I measure from the earliest known customer impact, not from Anthropic's own status updates. That mitigation restored most of the affected models (Mythos/Fable 5.1 and Opus 4.6), but Opus 4.8 and 5 were still unavailable.

That's a long time for such a critical service to be down. I do appreciate that Anthropic brought back both a leading-edge model and an older one, giving different kinds of customers something to switch to. The timeframe is the real problem.

Given the most likely root cause, the Colossus outage, I wonder whether Anthropic could have moved more inference to other data centers. It raises the question of how much spare capacity it has. Even at the cost of higher latency, serving customers that way beats a hard outage for some models.

xAI

This is very similar to Anthropic, except there was no intermediate mitigation before the full resolution, which took about 3.5 hours. Without any partial mitigation, Grok gets a 2.

OpenAI

The mitigation landed 34 minutes after the incident was opened and covered every affected service. That's a solid result, and it gets an 8. The only improvement would be faster, more automated mitigation. I was curious whether OpenAI rolled back the change or needed a roll-forward PR; the RCA answers that, as covered under Rollback vs. Rollforward below.

Time-to-resolve (TTR)Anthropic 🔴 2 / 10xAI 🔴 2 / 10OpenAI 🟢 8 / 10

Anthropic

Anthropic deployed a fix for the remaining models at 16:06 UTC, 41 minutes after its first mitigation and 2 hours 40 minutes after it declared the incident. Measured from the first user reports, that puts full resolution at about 3 hours 20 minutes. That's a long complete outage for those models, so it gets a 2.

xAI and OpenAI

For both of these, mitigation and resolution were the same event, so the scores match their TTM scores.

Blast radius reductionAnthropic 🟡 5 / 10xAI 🟡 5 / 10OpenAI 🟡 5 / 10

Anthropic and xAI

Both were heavily affected by the Colossus outage. Anthropic described the issue as "elevated error rates" rather than a complete outage, which suggests some requests were still being served, either at Colossus or at other data centers. Without a full RCA, it isn't clear whether all of Colossus was unusable or only part of its inference capacity. Knowing what percentage of traffic was affected would make exact scoring possible. For now, I'm giving both a 5.

OpenAI

An OpenAI spokesperson told Decrypt that only some users were affected, and that ChatGPT and Codex were unavailable for them. It isn't clear how many users "some" means, or how wide the original misconfiguration's impact was. According to Downdetector, customer reports peaked at 38,000. OpenAI indicated it wasn't a complete outage, but the extent is unknown, so it gets a 5.

Automated remediationAnthropic 🔴 1 / 10xAI 🔴 1 / 10OpenAI 🔴 1 / 10

Anthropic and xAI

There's no public record of how the Colossus outage was resolved. It took several hours, so there was probably no automated remediation in place. Elon Musk's statement that the company was "taking corrective action to ensure this does not happen again" makes that clearer still: it all but rules out a self-healing mechanism that would have resolved the issue on its own. Both get a 1.

OpenAI

Engineers rolled back the configuration change by hand, so there was no automated remediation here either. That gets a 1.

Rollback vs. RollforwardAnthropic N/AxAI N/AOpenAI 🟢 9 / 10

Anthropic and xAI

It isn't clear that the physical failure at Colossus could have been fixed with code or config. It was more likely a hardware problem, so rolling software forward or back may not apply. I'm marking this N/A.

OpenAI

OpenAI's RCA says explicitly that a rollback was used: "Engineers rolled back the configuration change to restore routing". It wasn't automated, but OpenAI clearly didn't need a follow-up PR to go through its CI/CD pipelines. That gets a 9; automated rollback would make it better, though that belongs more to automated remediation.

Prevention mechanismsAnthropic N/AxAI N/AOpenAI 🟢 9 / 10

Anthropic and xAI

Neither company has explained what it is doing to make its physical infrastructure more resilient, so there's no way to tell whether this could happen again. I'm sure both ran internal post-mortems with action items, but there's nothing public to judge. Both get N/A.

OpenAI

OpenAI's RCA lists these follow-ups, some already done and some in progress:

• Keep valid routes available during configuration changes. Simplify routing dependencies so an inactive destination does not cause healthy destinations to be removed from service. Also improve fallback behavior if the system receives an invalid configuration.
• Limit the reach of routing changes. Strengthen staged rollouts and evaluate health-check-based automatic rollbacks before changes reach more users.
• Reduce errors during recovery. Improve how returning traffic is distributed so recovering services are not overloaded.
• Detect and escalate routing failures sooner. We updated alerts to properly page outside business hours and are addressing monitoring delays and gaps in escalation.

These make route configuration changes backwards compatible, so healthy routes aren't removed before new ones are validated, and add fallback behavior that rejects invalid routes outright. They limit the blast radius of changes with staged rollouts and automated rollbacks. Finally, they cover traffic distribution and observability, so increased load is handled automatically and on-call engineers are notified sooner.

That addresses most of the lowest scores in this assessment. The one thing I'd add is a commitment to more frequent status page updates. This gets a 9.

CI/CD test coverageAnthropic N/AxAI N/AOpenAI N/A

This doesn't apply to any of the three. No roll-forward PR was needed: the only company that clearly needed a software change was OpenAI, and its change was a rollback.

Time-to-root-cause (TTRC)Anthropic 🟢 9 / 10xAI 🟡 4 / 10OpenAI 🟡 6 / 10

Anthropic

Anthropic published no RCA, but its status page shows it identified the cause 15 minutes after opening the incident. That's fast, so it gets a 9.

xAI

xAI published neither an RCA nor any status update saying when it understood the root cause. It did resolve the incident after about 3.5 hours, so I'm using that as its TTRC. That gets a 4.

OpenAI

OpenAI mitigated within 34 minutes of opening the incident, so it knew the root cause (the misconfiguration) sooner than that, somewhere between 5 and 30 minutes. That's not bad, and the mitigation time depended on both how quickly OpenAI understood the issue and how its rollback mechanism works. Because the incident was correlated with a deployment, TTRC should be quick, so I'd like to know whether it was closer to 5 minutes or 30. It gets a 6.

Root cause transparencyAnthropic 🔴 1 / 10xAI 🔴 1 / 10OpenAI 🟢 8 / 10

Anthropic and xAI

Neither company was transparent about the level of impact or what actually went wrong at Colossus. Given the severity, I expected a public RCA. They may want to keep details of Colossus private, but that doesn't build trust. xAI's only explanation is a brief post on X. Both get a 1.

OpenAI

OpenAI released its RCA promptly (within 48 hours), with a clear root cause, resolution, and action items. Questions remain about how many users were affected and in which regions or data centers, but the broad details are informative. It gets an 8.