Summary

  • A cleanup task passed an empty pending_delete query value. The Addressing API interpreted it as a request for all BYOIP prefixes, and the task removed prefixes and dependent service bindings.
  • About 1,100 prefixes were withdrawn. Roughly 800 could be restored through re-advertisement; around 300 had also lost edge service configuration and required a later global recovery. A route announcement was only one layer of service restoration.

The second recovery clock

Cloudflare’s account of 20 February 2026 is easy to summarize as a BGP outage. The more consequential detail sits after the routes began returning. Some customer prefixes were advertised again, but Cloudflare’s edge no longer had the service bindings that told it what to do with traffic for those addresses. The route came back before the service did.

The distinction matters because a public IP address is not an application. A prefix can be registered to a customer, authorized for a provider to announce, present in a provider’s address database, advertised by BGP, bound to a product, and configured across edge machines. Those states are related, but they are not interchangeable. A green route does not prove that a packet reaches the right customer service.

Cloudflare says the outage began when a regular cleanup sub-task tried to automate removal of prefixes that customers had asked to remove. The task sent pending_delete without a value. In the server implementation described in the postmortem, the filter only selected pending deletions when the parameter’s string value was non-empty. With no value, the request instead returned all BYOIP prefixes. The task treated every returned prefix as eligible for deletion, then removed dependent objects, including service bindings.

This was not an attacker changing routes. Cloudflare says the API release completed at 17:46 UTC, the cleanup task began running at 17:56 and routes started to be withdrawn. The process was identified and stopped at 18:46. About 1,100 prefixes were withdrawn during that period, which Cloudflare says was 25% of its 4,306 BYOIP prefixes advertised globally. The postmortem also describes a 6,500-prefix view to one peer; that is a different denominator and should not be substituted for the global BYOIP count.

The rollout was iterative, limiting the blast radius. It did not prevent the failure, but it meant the new behavior had not reached every customer before engineers stopped it. That is a valuable control: staged change can turn a universal failure into a partial one. It is not, by itself, a recovery plan.

Why “advertised” was not “working”

Cloudflare’s product description separates two operations. BGP advertisement attracts traffic for a prefix to Cloudflare. A service binding associates that traffic with a product such as CDN, Spectrum or Magic Transit. Address maps may add another layer for CDN traffic. If an automation error removes the prefix and its bindings, re-advertising the route can restore reachability to the provider’s network without restoring the product path at the edge.

That is what made the dashboard remedy conditional. Cloudflare told customers at 19:19 UTC that they could re-advertise their prefixes. Around 20:20, approximately 800 prefixes had been restored. Roughly 300 could not be repaired by toggling advertisement because the corresponding service configurations had been removed from edge systems. The customers could not recreate a binding that no longer existed in the configuration available to their account. Cloudflare engineers had to restore the missing state and propagate a global configuration update, completed at 23:03 UTC.

The company reported a total incident duration of six hours and seven minutes.

The public account does not give customer counts, geography, revenue losses or an SLA bill. It does describe distinct customer experiences: some had only a withdrawal; some had a partial loss of bindings; others had no service binding left and waited for provider-side configuration recovery. The same incident therefore produced different restoration paths behind the same label, “BYOIP outage.”

The outage also affected the website at one.one.one.one, which displayed HTTP 403 errors. Cloudflare states that recursive DNS resolution through the 1.1.1.1 Public Resolver, including DNS over HTTPS, was not affected. That distinction is operationally important: a visible website failure was evidence of impact on a BYOIP-hosted surface, not evidence that the resolver itself had stopped answering queries.

Configuration is part of the route

Cloudflare’s postmortem describes the Addressing API as an authoritative dataset whose changes were reflected in the global network. The system connected customer-facing requests to databases and workflows that changed advertisements and product bindings. In that design, the same stored state was used both to represent customer configuration and to drive operational actions. Cloudflare said this made manual rollback harder because engineers had to use database snapshots rather than compare intended state with observed state.

The test gap was also specific. Cloudflare says staging data and mock data were insufficient. Testing and code review covered the self-service journey a customer would follow, but not the scenario in which a separate task-runner service independently changed customer data without an explicit request. A task can be safe in the path that a user invokes and unsafe in the scheduled path that reuses its API. Testing only the interface leaves the automation principal outside the model.

The postmortem’s proposed remedies therefore reach beyond checking a query parameter. They include more standardized API schemas, a separation between configured and operational state, snapshots deployed through health-mediated rollouts, automatic stopping or rollback, and circuit breakers for changes that withdraw or delete prefixes too quickly or broadly. Cloudflare also described work to use customer-service health as a signal. These were announced follow-up steps; the February report alone does not establish which were later completed.

The economic promise of BYOIP is that a customer can keep a recognizable address identity while using a provider’s network and services. The operational bargain is more complicated: the customer may own the address block and grant authority to announce it, while the provider operates the control plane that withdraws the route, maps it to a product and distributes configuration to edge machines. A customer’s portable asset can still depend on state that the customer cannot restore alone.

That is not an argument against managed routing. It is a reason to define continuity at the service boundary. The Cloudflare documentation says a successful dynamic-advertisement API response confirms that a request was registered; route propagation takes additional time. It separately tells customers to have service bindings complete before advertising a production prefix. A control-plane acknowledgement and a working service are different proofs.

What a continuity claim should demonstrate

For a customer, the useful question is not simply whether a provider can announce a prefix. It is whether the customer can determine which state has failed and what recovery authority applies. A continuity schedule should distinguish at least four milestones: 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. Each milestone has a different owner and clock.

The incident suggests a practical acceptance test for provider relationships: ask for a recovery exercise in which the route is present but the service binding is missing. Can the provider identify that condition from telemetry? Can it restore one customer’s configuration without a risky global database rollback? Can it show that service health, not merely route count, gates further rollout? What can the customer change during an incident freeze, and which actions would make recovery worse?

Customers can plan a second advertisement path, but that is not a universal substitute for provider recovery. Cloudflare’s operational guidance warns that overlapping announcements and route preference must be managed deliberately; a second route is valuable only when ownership, origin authorization, traffic handling and service behavior have been tested together. A fallback that attracts packets to a network without the application state simply moves the failure.

The larger lesson is modest and measurable. 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. Continuity reporting should not collapse those layers into one status badge. The prefix returning was progress. It was not the end of recovery.

Sources