If Claude Going Down Stops Your Team, You Have a Reliability Problem

The outage isn't the surprise. The stall is.#

StatusGator counted 156 Claude outages since January 2026. Seven of them landed across four separate days in a single week of July, ranging from 20 minutes to two and a half hours. This is not a freak month; it is the measured shape of the service.

• July 22, 20 minutes, claude.ai and Cowork
• July 25, two separate incidents, 52 minutes and 1 hour 5 minutes
• July 26, 1 hour 20 minutes
• July 27, three incidents, 50 minutes to 1 hour 5 minutes each

Anthropic's own status data puts api.anthropic.com at 99.6% uptime and claude.ai at 99.32% over a rolling 30 days, roughly five hours of downtime a month. Most enterprise software contracts target 99.9% or better. Forbes reported that Anthropic's own enterprise SLA is 99.99%, but it is negotiated case by case, with service credits capped at 5-10% of the monthly bill, not a default guarantee on the tier most teams are actually running.

None of this is a knock on Anthropic's engineering. Anthropic's own leadership has pointed to demand outrunning infrastructure, with annualized revenue jumping from roughly $9B at the end of 2025 to over $30B by early April 2026. Growth at that pace strains any provider. What it means for a reader running a team is simpler. This is not a rare event to shrug off. It is a recurring condition to design around.

You have a disaster recovery plan for everything except the thing you run on#

Omdia analyst Mike Leone put it plainly, describing enterprises that "have disaster recovery plans for every layer of their infrastructure, but almost none of them have thought about what happens if the AI model running their product goes away tomorrow." Swap "product" for "pull request queue" and the sentence still lands.

Elizabeth Ngonzi of the American Society for AI names the actual mechanism in the same InformationWeek piece. "The real risk is not the tool, it's how tightly organizations bind themselves to it." A model API rarely arrives as a declared infrastructure decision. It arrives as a convenience, then a habit, then the thing three teams quietly depend on without anyone signing off.

A Microsoft Azure devblog account documented what that dependency looks like mid-collapse, not in theory. "Responses started dragging. 30 seconds. Then 4+ minutes per tool call. Not erroring, just slow enough to be useless." The fix that shipped from that incident was not a retry loop. It was running a second coding agent against a different backend, so a developer could swap tools in seconds instead of watching a spinner.

That is the tell. "Every major provider has had significant degradation in the past six months," the same account notes. This has stopped being an Anthropic-specific risk. It is what it looks like to run a business-critical workflow on infrastructure you don't operate and can't page.

Switching providers isn't free, and pretending otherwise is its own kind of denial#

The honest counterargument deserves real airtime, not a strawman paragraph. Models are not interchangeable sockets. Prompts tuned against one model's quirks can behave differently on another, and swapping the model underneath a production workflow means re-validating output quality, not just re-pointing a URL. Running two providers in parallel costs real infrastructure, real credential management, and real engineering time nobody budgeted for.

That cost is exactly why so many teams skip it, and it is a legitimate reason to skip it for a Tuesday afternoon side projectProjectsA Claude Desktop feature giving a persistent workspace its own chat history and knowledge base, so uploaded documents and instructions carry into every chat inside it.See also Artifacts, Quick Entry. It stops being legitimate the moment the workflow behind it is load-bearing. A team that would never run a production database with zero replicas has, in most cases, wired an equally load-bearing dependency to a single vendor with zero fallback, and called the difference a technicality.

The point isn't "add a fallback model for everything." It's pricing the tradeoff honestly, in advance, instead of discovering it live during an incident.

The fix is the same seven parts you already keep for a database#

Kong's production framework for surviving a provider outage names seven parts, and none of them are exotic.

• An abstraction layer that normalizes provider APIs behind one endpoint
• Priority-based routing across providers
• Fallback chains, "ordered sequences of backup providers that activate automatically when a higher-priority provider fails or degrades"
• Circuit breaker thresholds that catch a bad error rate before it cascades
• Health checks on every provider in the chain
• Credential isolation per provider
• Regular failover drills

That is the same shape as a database's read replica, a load balancer's health check, a payment processor's secondary gateway. None of that means shipping all seven parts before Friday. The first move is smaller. Write down the manual switch procedure for the one workflow that actually stops the team, and name the second model or the degrade path it falls back to. The abstraction layer, routing, and drills earn their place once that one workflow is proven load-bearing, not before.

This repo's own publishing pipeline, the one that writes and ships posts like this one, is a fair test case, and it fails its own argument. Every stage runs inline, in one model context, on one vendor, by design, to avoid the token cost and information loss of splitting the work across agents. Stage 6 already calls out to a second, deliberately different model for cross-model review, proof that the multi-provider plumbing exists in this stack for exactly one reason unrelated to uptime. It was never pointed at availability. That gap sat there not because the fix was hard, but because nobody asked what happens if the one vendor the whole pipeline depends on has an incident mid-publish.

That is usually the actual story behind a team stopped cold. Not that resilience was impossible. That it was one config change away and simply never got prioritized, because the outage that would have justified it hadn't happened yet.

Keep betting on one vendor. Just know what you're betting.#

Vendor lock-in fear is not rare. Kong's own research found 94% of respondents worried about it, and 58% who had already lived through a failed migration. Neither of those numbers is an argument against a fallback planplan modeA Claude Code CLI mode that reads files and runs commands to explore a codebase but holds off making any changes until the user approves a proposed plan.See also Shift+Tab cycle, permission modes. They are an argument for treating one as infrastructure, priced in advance, rather than a postmortem action item written the week after the outage that made it necessary.

A single-vendor bet is a legitimate choice for a team that has actually weighed it and decided the switching cost outweighs the downtime cost. Weighed is the word doing the work. A 2-hour incident that takes the whole team offline, with the retro's only finding written as "Claude was down," is not a decision. It's an accident wearing one. What breaks a team is never the outage itself. It's discovering, live, that nobody ever asked what happens next.