Everyone Blamed Cloudflare. It Was a Fibre Cut at Zayo.

Last Monday, 22 June 2026, a large part of the web started timing out at once. X, Zoom and some Google and Microsoft services were all reported degraded, and the cause was a fibre cut in Eastern North America on the network of Zayo, one of the handful of Tier 1 backbones that buy transit from nobody. 1

Not a software bug. Not a cyberattack. A severed cable.

The reflex, in the reporting and on social media, was to call it a Cloudflare outage. Cloudflare said otherwise, and said it flatly: it was not seeing a global outage of its own, the problem was on Zayo's routes, and sites depending on Zayo alone could be unreachable whether or not they used Cloudflare. 1 What got reported was increased error rates, elevated latency and intermittent timeouts rather than a clean global failure. 1

The timing was awkward for us. We published a piece on physical path diversity that same morning, arguing that redundant connectivity frequently isn't. The afternoon made the argument better than the article did.

The layer nobody diagrams

There's a version of this story that's about Cloudflare, and it's both the popular version and the wrong one. Cloudflare's own position was that its network wasn't at fault, and that the disruption originated one layer below it, in a backbone carrier that sits underneath a lot of networks, Cloudflare's included.

The interesting version is about why everyone guessed wrong.

A single cable fault shouldn't be able to degrade X, Zoom and parts of Google and Microsoft at the same time. Those are enormous, independently engineered, well-funded platforms with large engineering teams who have all done resilience planning. They degraded together because they were exposed to the same dependency, one that sits below the application and below the CDN, and many organisations don't treat it as a single point of failure, because it isn't a server and it isn't in their diagram.

That's the actual lesson of 22 June, and the misattribution is the proof of it. Cloudflare is visible. You choose it, you configure it, it has a dashboard and a status page, so when things break it's the first name to hand. Transit is invisible. Almost nobody chooses their carrier's carrier, and almost nobody could name the backbone their packets crossed on the way to a customer.

Reverse proxies, CDNs and DDoS scrubbing are a concentrated layer, and DNS is another concentrated layer beside them. Underneath all of it sits a much smaller number of backbone networks, and that layer is more concentrated still.

Not independence, just not helpless

There are limits to what redundancy can solve. You can't make a backbone cut not happen, and you have no contractual relationship with the carrier that failed. The goal isn't eliminating dependencies. It's still having options when one of them fails.

Keep your origin reachable. If your origin only accepts traffic from your CDN's IP ranges and has no other path in, you can't fail away from the CDN. Keep a working, tested direct route even if it normally serves nothing.

Keep DNS somewhere else. If your DNS and your proxy are the same vendor, their bad day removes both the problem and your ability to route around it. This is the highest-value split available.

Know your TTLs before the incident. A 24-hour TTL means your failover takes a day regardless of how fast you notice.

Have a static fallback, a plain page on a different provider in a different country that says what's happening. It costs almost nothing and it's what your customers want during an incident.

Then practise it, because a failover path that has never been executed is a hypothesis.

The role we can play

We're a small European ISP rather than a backbone, and that's where a smaller independent provider is actually useful here. We're the place your fallback lives.

A €5/mo VPS in Tirana, Skopje, Amsterdam or Dublin is enough to hold a static status page, a secondary DNS server, a direct-to-origin path, or a cold standby that doesn't share a control plane, a company or a continent with your primary stack. Full KVM with root access, DDoS protection included, crypto accepted, no KYC, running in minutes.

For customers who want the network layer under their own control, AS210464 offers BGP sessions from €5/mo, RPKI validation, and a community set that lets you move your own announcements between our regions, including remote-triggered blackholing when you need traffic dropped at our edge rather than at your server.

You can watch our paths yourself, without an account, through the looking glass. Run a traceroute from the networks you care about to each of our sites and look at which networks appear in the middle of every one of them. Traceroute won't show you MPLS hops, asymmetric return paths, or anything a router declines to answer for, so treat it as a first look rather than an audit. A transit provider that turns up on every path is still worth knowing about before it has a bad day.

The lesson nobody wants

The internet's resilience story has always been that packets route around damage. That was true when the damage was in the middle of a mesh. It's much less true when the damage is in one of the handful of backbones that nearly everything now crosses.

The layer that failed on 22 June is the one with no dashboard, no status page you subscribe to, and no line in your architecture review. That's not an argument for panic. It's an argument for knowing which networks your traffic depends on before the next cut, because the answer takes ten minutes to find and nobody looks it up during an incident.

Sources

1. Cloudflare Outage: Fibre Cut in Eastern North America Triggers Internet Disruptions, Latestly, 24 June 2026