A transit provider outage degrades Cloudflare for nearly three hours in North America
On October 23, 2026, from 15:47 to 18:43 UTC, an outage at a connectivity provider congested the links between Cloudflare’s Ashburn and Atlanta data centers, degrading services with no direct connection to that provider. For anyone who depends on a CDN or a cloud, the lesson is plain: redundancy is verified, never assumed.
October 23, 2026. Cloudflare begins investigating degraded performance on traffic between its Ashburn and Atlanta data centers. 16:07 UTC. The team identifies an outage at a connectivity provider and starts rerouting traffic away from the affected paths. 18:43 UTC. The incident is marked resolved, after two hours and fifty-six minutes. The point that matters: a single, never-named transit provider was enough to degrade services that had no direct connection to it — and the failure recurred after a first fix.
What happened, minute by minute
The timeline, as Cloudflare published it on its status page, fits in eight updates. At 15:47 UTC, the team opens the incident: degraded traffic between Ashburn and Atlanta, with latency, packet loss, and intermittent errors on Workers and other services in the eastern United States. At 16:07 UTC, the diagnosis lands: an outage at a connectivity provider is causing network congestion. Rerouting begins.
At 16:27 UTC, a fix is applied and the team starts monitoring. At 17:03 UTC, the provider’s failure recurs, and Cloudflare resumes traffic management to route around the failing links. At 18:18 UTC, traffic is rerouted around the affected paths and packet drops stop; the provider reports its service restored, but some links are still coming back, so Cloudflare keeps its traffic changes in place. At 18:43 UTC, the incident closes.
Why a transit outage hits unrelated sites
Cloudflare is not just a CDN. It sits between a great many websites and their visitors, and it also carries traffic for customers’ applications and APIs. When the paths between two of its data centers degrade, traffic riding those paths slows or fails — even when a customer’s origin servers are running perfectly.
That is the key mechanism of this episode. The initial failure sits with a transit provider, one of those wholesale operators that interconnect networks with each other. When its links between Ashburn and Atlanta become congested, Cloudflare does not “go down”: it congests. End users then see errors on services that hold no direct contract with the faulty provider — the failure of an invisible link in the network shows up, at the end, as sites that stop answering.
The geography matters too. Ashburn and Atlanta are among the densest interconnection points on the North American internet; a large share of East Coast traffic transits through them. When a link between two such hubs degrades, the affected region is not a single city but a broad swath of the continent — because so many networks have chosen, for sound economic reasons, to meet in the same two places. Diversity of providers counts for little if every provider funnels through the same geography.
The recurrence: the signal everyone underweights
The most instructive detail is not the outage, but its recurrence. At 16:27 UTC, a fix is in place; at 17:03 UTC, the provider fails again. A first remediation that does not hold for an hour is a strong signal: the problem was not a one-off incident, but an unstable state of the provider, to be routed around rather than repaired.
For an operator, this is the difference between “redundancy” and “rerouting.” Cloudflare did not flip to a backup path in one second: it took nearly three hours to stabilize traffic, keeping its changes in place even after the provider announced recovery, because links were coming back in fits. The lesson is blunt: an alternate path is useless if no one has tested it, and an unstable provider should be removed from the production plan, not “watched closely.”
The opacity of an unnamed provider
Another notable point: Cloudflare never named the connectivity provider at fault, and published neither the number of affected customers nor the volume of failed requests. This discretion is customary in the transit industry — contracts between networks are rarely public — but it carries a cost: customers cannot tell whether their own redundancy unknowingly rested on the very link that just broke.
The same day, Downdetector recorded spikes in US reports for Canva, ChatGPT, Reddit, Zoom, Microsoft 365, Discord, and Cloudflare. Those spikes do not prove a common cause, and nothing officially ties those services to the Cloudflare incident. But the timing coincidence illustrates a structural fact: when a large intermediary congests, complaints surface everywhere at once, without any single customer able to draw the connection.
Concentrated, silent transit providers
The transit market is one of the most concentrated layers of the internet. A handful of wholesale operators — the Tier 1 networks — interconnect most of the world’s traffic, and their failures, when they happen, do not make headlines: they surface as latency, packet loss, and intermittent errors that customers wrongly attribute to their own servers.
That concentration has a direct consequence for redundancy. Two paths that “look” different often cross the same transit AS a few hops later, because peering agreements and costs push networks to interconnect with the same large links. Checking redundancy is therefore not a matter of ticking “I have two providers”: you must trace the paths to the end and make sure they do not converge on the same point of failure.
What teams should take from it
Network monitoring too often reduces to a ping at one’s own site. This episode shows you must watch the paths, not just the destinations.
# Follow the real path and per-hop loss (Linux)
mtr -rwzbc 100 1.1.1.1
# Check path diversity toward a critical service
traceroute -n api.example.comAn mtr showing loss concentrated on one intermediate hop — the AS of a transit provider, say — says more than a simple “the site responds.” It reveals which link your traffic depends on. The question to ask is not “is my provider reliable?” but “what breaks if its link to my data center congests?”
Beyond the path, watch the BGP table. A withdrawn announcement, a prefix shifted to another AS, a spike in route changes are often the first signs of a transit incident, before packet loss even appears. Public tools — RIPE RIS, route-views, or Cloudflare Radar for routing anomalies — let you see what is changing on the paths that matter to you, without waiting for a vendor’s status page.
Three hours is long on the scale of a Cloudflare incident, and it is exactly how long it took to route around an external link. The number recalls a network-engineering truth: you do not “repair” a third-party provider, you route around it — and rerouting is prepared cold, not during the incident.
Verdict
If your service depends on a CDN or a cloud that concentrates your traffic, do not mistake advertised availability for real redundancy: the October 23 failure did not take Cloudflare down, it congested it, and perfectly healthy sites returned errors for nearly three hours. If you have a continuity plan, exercise it — a reroute that has never been rehearsed is a wish, not a plan. And if your redundancy relies on two paths that cross the same transit provider, you have no redundancy: you have the same point of failure twice. The network is more centralized than it looks, and the next transit outage will not announce itself either.