When Three AI Platforms Failed at Once: The Resilience Lesson for Enterprise IT

On the morning of 3 September 2026, three of the world’s leading AI platforms failed within the same window. Anthropic’s Claude began logging elevated errors from around 6:23am Pacific time and stayed degraded for roughly three hours. xAI’s Grok went down minutes later, which the company traced to an outage at its Memphis compute facility. OpenAI’s ChatGPT and its Codex coding tool then dropped for 34 minutes later that morning, attributed to a routing error (The Register). By most accounts there was no single shared cause. Three separate providers, three separate failures, overlapping by coincidence rather than a common root (Axios).

For a lot of large organisations, that morning was more than an inconvenience. Developers lost their coding assistants mid task. Customer service teams that route queries through AI lost that layer. Analysts and knowledge workers who now draft, summarise and check work with these tools found themselves back to doing it by hand. None of this made headlines for long, but it should sit with any technology leader who has quietly let AI tools become part of the operating fabric of the business.

The uncomfortable pattern

What makes this event worth a closer look is not its length. Three hours of Claude errors and a 34 minute ChatGPT outage are, on their own, unremarkable by the standards of enterprise IT. What matters is the pattern it fits into. Forrester’s analysts have been warning through 2026 that hyperscalers are redirecting investment toward GPU heavy, AI focused infrastructure and away from the legacy systems that underpin general reliability, and they expect at least two major multi day outages at a hyperscale provider before the year is out (Forrester, via Forbes). Their advice to enterprise buyers is blunt: disaster recovery plans should now assume a primary AI or cloud provider can be unavailable for 72 hours or more, not just an afternoon.

That is a meaningfully different planning assumption than most organisations are working from today.

Availability used to be someone else’s problem. For years, enterprise IT treated large cloud and SaaS providers as close enough to always on that formal continuity planning focused on the organisation’s own systems, not the vendor’s. AI services have been adopted on the same assumption, often faster and with less governance than the cloud migrations that preceded them. The September outage is a reminder that assumption was already fraying before AI arrived, and AI workloads add a new layer of concentration risk on top of it.

Why this is different from a typical SaaS outage

A short outage in a CRM or email platform is annoying but rarely stops work. AI tools are increasingly wired into processes that produce something, not just store or route information: code, customer responses, analysis, drafts that feed into decisions. When that layer disappears, the fallback is often a person doing the task manually, at a fraction of the speed the process was designed around. Few organisations have actually tested what that fallback looks like at scale, because until recently there was little reason to.

There is also a vendor concentration question. Many enterprises now depend on AI capability from one or two providers embedded across multiple internal tools, from coding assistants to customer facing chat to internal search. A single provider incident can therefore ripple through several unrelated business functions simultaneously, which is precisely what made the 3 September morning notable even without a shared technical cause.

What a sound response looks like

None of this argues against using AI. It argues for treating AI providers the way mature organisations already treat other critical vendors.

• Map the dependency, not just the tool. Know which business processes stop, degrade gracefully, or fail silently when a given AI service is unavailable, and for how long that is tolerable.
• Set a real recovery time objective for AI dependent workflows, and design a manual or secondary path for anything above your tolerance.
• Avoid single provider concentration in functions that matter most, even where that means more integration effort up front.
• Extend existing business continuity and vendor risk frameworks to AI providers explicitly, rather than assuming they are covered under a general SaaS category.
• Rehearse the failure, not just the plan. A tabletop exercise that assumes your primary AI provider is down for a day will surface gaps no policy document will.

The organisations best placed to absorb the next AI outage will not be the ones with the most AI. They will be the ones that already know exactly what happens to their business the moment it stops.

The regulatory backdrop is moving the same direction

Boards should also note that resilience expectations are hardening in parallel through regulation. EU rules under the Cyber Resilience Act now require manufacturers to report actively exploited vulnerabilities from mid September 2026, and public sector procurement in several jurisdictions is beginning to weigh sovereignty and continuity alongside price and features (SoftwareOne). Operational resilience is shifting from good practice to a compliance expectation, particularly for organisations serving government or regulated sectors.

Where Jaykan fits

Jaykan helps large organisations and government bodies build the operational discipline that AI adoption now demands, from vendor risk assessment and business continuity planning through to designing resilient, multi provider architecture for critical workloads. We help clients work out exactly where AI dependency sits in their operations and what a credible fallback looks like, before an outage forces the question.

If you are not confident your organisation could answer that question today, a complimentary, senior led assessment is the fastest way to find out. You will leave with a clear picture of where AI and cloud dependency creates risk, and a practical plan to close the gap.