The Claude Outage Was Visible in BGP Before the Status Page Moved

On July 29, Anthropic’s status page reported simultaneous major outages across claude.ai, the Claude API, Claude Code, and Claude Cowork. Two products stayed up: Claude Console and Claude for Government.

I did not learn about the outage from the status page. I saw it in the global routing table.

What I was watching

I run a passive network intelligence platform that collects BGP routing signals from public RIPE RIS collectors. At the time of the outage it held 4.69 billion signals covering 31 days of continuous observation. It applies Hodge decomposition to routing activity, which separates each signal into gradient, curl, and harmonic components. The short version: gradient and curl describe routing that is changing on purpose. Harmonic describes routing that will not settle.

Nothing in this analysis touches private data. Every signal is public. Anyone peering at the right exchange points sees the same updates. The work is in the decomposition, the baselines, and knowing which prefixes matter.

What the data showed

At 15:00 UTC, the harmonic count on Amazon (AS16509) prefixes jumped to 15 against a 31-day baseline of 4 to 5 per hour. The affected prefixes sat in the 130.137.0.0/16 and 173.82.0.0/16 blocks, which are AWS CloudFront edge infrastructure. At 19:00 UTC a second wave hit 44 harmonic signals, nine times baseline, on the same prefix family.

Two details stood out. First, withdrawals never spiked. Routes stayed up all day. Whatever was happening, it was not a reachability failure. The infrastructure was reachable and unstable at the same time, which is exactly what users experience as intermittent errors rather than a dead site.

Second, the fine structure was diagnostic. One CloudFront prefix completed a full flap cycle in 14 seconds: withdrawal, re-announcement, path change. In both anomaly windows, blocks of /24 prefixes were announced simultaneously, down to the millisecond. That simultaneity is the signature of a single BGP speaker bringing capacity online, which is what load balancer failover or an availability zone activation looks like from the outside.

The two-wave signature

The day had a shape: a first anomaly at 15:00 UTC, a quiet period through 17:00 and 18:00 UTC, then a second, larger anomaly at 19:00 UTC on the same prefixes.

That shape has a name in incident response: failed remediation. An initial failure triggers a fix that produces brief apparent stability, then the problem returns worse than before, because the mitigation itself introduced new instability. The second wave carried three times the harmonic count of the first.

The correction that made the analysis better

My first pass attributed a 16:02 UTC anomaly burst to Cloudflare. That was wrong, and the way it was wrong is the most interesting part of the story.

While mapping entities, I confirmed that Anthropic operates its own autonomous system, AS399358, registered in 2023, with RPKI-valid prefixes and transit from both Cloudflare and Cogent. Re-reading the 16:02 UTC signals with that map in place showed the burst was an Anthropic IPv6 prefix on the Cogent path re-establishing routing through an alternate upstream after the first wave. Not a Cloudflare event. Anthropic’s own routing, reconverging.

Getting entity attribution right changed the interpretation of the timeline. The lesson generalizes: routing data without an entity map produces confident wrong answers.

The 31-day context

With AS399358 mapped, I could pull its full history from the dataset and compare it against Anthropic’s public incident log. The two weeks with anomalous routing activity, the weeks of July 13 and July 20, map directly onto the two most severe documented incident clusters in that period. The quiet weeks in the routing data were quiet on the status page too.

The public incident history shows 15 consecutive days with at least one documented incident from July 15 through July 29. And one pattern repeats: on July 21, July 22, and July 29, the exact same product list went down while Console and Government stayed up each time. From the outside, that consistency reads as a structural divide. Something separates the surviving products from the affected ones at the infrastructure level, and it holds across incidents.

Why this matters beyond one outage

Status pages are written by the people fighting the fire, after triage. Public routing data updates in real time and nobody curates it. For anyone operating infrastructure that depends on cloud-hosted services, a harmonic spike on your vendor’s prefixes is an earlier signal than anything the vendor will tell you.

There is also a systemic finding buried in the day: AWS, Meta, and Oracle showed simultaneous routing anomalies at the same two timestamps. Those companies share no application infrastructure. They do share transit providers and exchange points. Correlated routing anomalies across unrelated companies point at the internet substrate itself, which is a risk that no individual company’s monitoring can see.

What comes next

This analysis was performed during the event, from public data, with no inside knowledge. When Anthropic publishes a post-mortem, the routing observations get their test: does the first harmonic spike line up with their internal timeline, and does the two-wave structure match their remediation history? I will publish that cross-validation as a follow-up either way. If the routing signals called it right, that validates the method. If they did not, that calibrates it. Both outcomes are useful.