A Restored Route Is Not a Restored Internet: The Hidden Layers of Cloudflare's BYOIP Outage

This week, the internet's most instructive outage got a second hearing. On October 14, the industry publication btw.media published a detailed dissection of Cloudflare's February 20, 2026 outage of its Bring Your Own IP (BYOIP) service, and the conclusion should retire a comforting assumption most of us carry: when the internet's map says a destination is reachable, that does not mean the destination is working. The routes came back. The service did not, not for hours. Understanding why requires a short tour through the layered machinery that quietly moves every packet you send.

What happened on February 20

Cloudflare's BYOIP product lets companies keep their own public IP address blocks while Cloudflare announces them from its global network and ties them to products like its CDN, Spectrum, and Magic Transit services. As part of its "Code Orange: Fail Small" reliability initiative, Cloudflare was automating a manual chore: deleting prefixes that customers had asked to have removed. The Addressing API release completed at 17:46 UTC on February 20, and a cleanup sub-task began running at 17:56 UTC.

The cleanup task asked the API for the list of prefixes marked for deletion, using a query parameter called pending_delete. The parameter went out with no value attached. On the server side, the filter only selected pending deletions when the parameter's string value was non-empty, so the malformed request returned every BYOIP prefix in the system instead. The task treated that entire result as the deletion list. By the time engineers identified and stopped the process at 18:46 UTC, roughly 1,100 prefixes had been withdrawn from the global routing table, about a quarter of Cloudflare's 4,306 BYOIP prefixes announced worldwide.

The withdrawal alone would have been serious. What made the incident genuinely hard to recover was the dependent state the task shredded along with the prefixes: the service bindings that connect those IP addresses to Cloudflare's core products, the configuration that tells thousands of edge machines exactly what to do with traffic arriving for each address.

Why advertised is not the same as working

Here is the layer the incident exposed. An IP address block is a name. A BGP announcement is a claim: this network can carry traffic for these addresses. A service binding is a decision: traffic for this prefix belongs to this product, on these terms. Edge configuration is the execution: every server in the network knowing what to do with the packets. Those states are related, but they are not interchangeable, and re-announcing the claim does not restore the decision.

That is why recovery ran on two separate clocks. At 19:19 UTC, Cloudflare told customers they could re-advertise their prefixes from the dashboard. By about 20:20 UTC, roughly 800 prefixes were back in the global routing table. But around 300 could not be fixed by toggling advertisement at all, because the corresponding service configurations had been removed from edge systems. Customers could not recreate bindings that no longer existed anywhere in their accounts. Cloudflare engineers had to restore the missing state themselves and propagate a global configuration update, which completed at 23:03 UTC. The company reported a total incident duration of six hours and seven minutes.

An address is a name in the routing system; a route is a claim about reachability; a binding is a decision about where traffic goes; and a live service is an outcome. The prefix returning was progress. It was not the end of recovery.

The empty query parameter

The technical root cause fits in one sentence, and that is what makes it alarming. A scheduled job sent an API parameter with an empty value, the server read emptiness as "match everything," and automation did exactly what it was told. Cloudflare's postmortem says the test gap was equally specific: staging and mock data covered the journey a human customer takes through the self-service dashboard, but not the scenario in which a separate task-runner service independently changed customer data with no human in the loop. A task can be safe in the path a user invokes and unsafe in the scheduled path that reuses its API.

The design of the system amplified the blast radius. Cloudflare's Addressing API functioned as an authoritative dataset whose changes flowed straight into the global network, connecting customer-facing requests to databases and workflows that altered advertisements and product bindings. Because configured state and operational state shared the same store, engineers could not simply compare intended state with observed state; recovery depended on database snapshots, a far riskier lever to pull.

One detail from the postmortem is worth keeping straight, because it briefly confused observers at the time. The website at one.one.one.one displayed HTTP 403 errors during the outage, but Cloudflare states that recursive DNS resolution through the 1.1.1.1 public resolver, including DNS over HTTPS, was not affected. The visible website failure was a BYOIP-hosted surface going dark, not the resolver itself stopping.

What a recovery report should prove

The btw.media analysis proposes a continuity standard that customers can actually use. A recovery claim should demonstrate at least four distinct milestones, each with a different owner and a different clock: the withdrawal stops; the prefix is visible again in external route observations; its service bindings and edge configuration are restored; and the customer's application traffic succeeds. A status dashboard that collapses those layers into one green badge is telling a story, not reporting a state.

There is a practical test hiding in that standard. Ask a provider to run a recovery exercise in which the route is present but the service binding is missing. Can its telemetry even identify that condition? Can it restore one customer's configuration without a risky global database rollback? Can it show that service health, not merely route counts, gates further rollout? Customers who run their own fallback should also know that a second advertisement path is no universal substitute for provider recovery. As Cloudflare's own operational guidance warns, overlapping announcements and route preference must be managed deliberately; a fallback that attracts packets to a network lacking the application state simply moves the failure somewhere else.

Cloudflare's announced remedies reach beyond checking one query parameter: more standardized API schemas, a separation between configured and operational state, snapshots deployed through health-mediated rollouts, automatic stopping and rollback, and circuit breakers that trip when prefixes are withdrawn or deleted too quickly or too broadly. The company also described work to use customer-service health as a rollout signal. The February postmortem announced these as follow-ups; the October analysis notes, fairly, that the postmortem alone does not establish which ones were later completed. That is itself part of the lesson. A provider's map of the internet is drawn from its own configuration, and when the configuration is wrong, the map lies. The fix is not only better code, it is better proof, layer by layer, that the map matches the territory.