Claude Code Went Down for Three Hours on 28 August. Some Teams Didn't Even Notice.

On Friday 28 August 2026, Claude Code on the web and Claude Cowork started throwing errors for close to three hours, rated Major impact by Anthropic. If your team runs agents on those surfaces, you likely watched sessions refuse to start, or die halfway through a task. Below: what happened, how it stacks up against a rough year of 2026 incidents, and what actually keeps a bad provider day from reaching your users.

What caused the Claude outage on 28 August 2026?

Anthropic blamed an upstream cloud provider and didn’t name it. Its status page logged the incident as “Elevated errors on Claude Code and Claude Cowork” with Major impact. This wasn’t a full Claude blackout. Claude.ai chat and the core API stayed up. The damage was confined to Claude Code on the web and Claude Cowork, where sessions failed to start or dropped mid-task.

The timeline was short but painful for anyone in the middle of work:

• 17:22 UTC: Anthropic identifies the issue
• 18:21 UTC: mitigation applied
• 20:21 UTC: fully resolved

That’s just under three hours end to end. You can check the record yourself on status.claude.com, and two third-party trackers, StatusGator and Pulsetic, logged the same window: StatusGator’s Claude outage history and Pulsetic’s incident log.

Is this the same as the July outage?

No, but it rhymes with it. In July 2026 Anthropic went down for three hours, a story we covered in Anthropic’s July outage. Roughly a month later, a different Anthropic surface fell over for almost exactly the same length of time, from a different cause.

Zoom out and the gap between the two incidents gets more interesting. 2026 has been a rough year for Claude reliability. A worldwide outage on 2 March followed a traffic spike from the Import Memory feature launch. A nearly 19-hour intermittent degradation ran across 26 and 27 March, traced to internal networking performance problems. August brought a cluster of incidents across model endpoints, platform surfaces, login, and even Anthropic’s status page itself. The 28 August outage was narrow. The pattern behind it isn’t.

None of this is a knock on Anthropic specifically. Every large provider has bad days. The point is that if your product depends on one provider and one route to it, their bad day becomes your bad day, which is exactly the risk we broke down in why single-model setups carry this risk.

What the outage broke for teams running Claude Code or Cowork

The real cost was failed sessions and mid-task drops, and both are worse than a plain error message. A session that refuses to start is annoying. A session that dies three steps into a multi-step job leaves half-finished work, unclear state, and a user who has to start over and wonder whether anything ran twice.

For teams shipping agents on Claude Code or Cowork in production, three hours of that means support tickets, manual reruns, and engineers dropping what they were doing to babysit a provider incident they can’t fix. Single-model dependency exposes you to more than outages, too. The same soft spot covers rate limits, latency spikes, model regressions, breaking API changes, pricing changes, commercial cutoffs, and regulatory changes. An outage is just the version that shows up on a status page.

So what actually stops this?

The fix is to stop treating one provider as a single point of failure, using resilience patterns that predate AI by decades. A few worth knowing:

• Fallback chains. When one provider fails, requests route to an independent second or third provider instead of erroring out.
• Health-aware routing. The system watches for errors, timeouts, and slowdowns, and steers traffic toward routes that are actually healthy.
• Retries with backoff and jitter. Transient failures get retried on a staggered schedule so you recover from a blip without hammering a struggling provider.
• Circuit breakers. Once a route is clearly failing, traffic stops flowing to it for a while so it can recover rather than pile up.
• Graceful degradation. When the ideal path is down, you serve a reduced but working response instead of nothing.

None of these are exotic. They’re standard reliability engineering, applied to model providers instead of databases or payment gateways. The hard part isn’t the ideas. It’s building and maintaining them across every agent you run, especially once you’re managing a stack of purpose-built agents instead of one generic setup.

How Autohive’s routing layer handles a Claude outage

Autohive sits a routing layer between your agents and the model providers, so a single provider incident doesn’t have to reach your users. If one route returns errors, times out, hits a rate limit, goes unavailable, or slows down, traffic can move to another available path. Autohive connects to eight providers and 52 models, and reaches Claude through both Anthropic direct and AWS Bedrock, so “Claude” isn’t tied to one door.

That model abstraction is the part that saves you rebuilds. You can change a model route without touching an agent’s prompt, knowledge base, integrations, or its position in a workflow. The business logic stays put while the infrastructure underneath it moves. In practice, that means fewer user-facing interruptions, less firefighting when a provider wobbles, and lower switching costs when you’d rather match a model to a task than marry a vendor.

If you want the deeper technical read on how the routing behaves during a degradation, we cover that in a companion piece on how Autohive handles model fallbacks. Worth pairing with choosing the right AI model for your agent if you’re deciding what to route to in the first place.

The 28 August outage lasted under three hours. The question it raises lasts longer: when your provider has its next bad day, does your product go down with it, or somewhere else?