Most big outages start with something mundane. Cloudflare’s on February 20, 2026 started with a query parameter that had no value in it.

Cloudflare lets large customers bring their own IP address ranges (BYOIP) and have Cloudflare announce them to the internet. That afternoon, a newly deployed automated cleanup task went looking for prefixes marked for deletion, asked the internal API for them, and got back every BYOIP prefix instead. It then started deleting them, along with the service bindings that tell Cloudflare what to do with the traffic.

What broke

According to Cloudflare’s post-mortem, the faulty change was merged on February 5 and deployed at 17:46 UTC on February 20. The cleanup sub-task sent its request with an empty pending_delete value. The server side interpreted an empty filter as no filter at all, and returned the full list.

Between 17:56 and 18:46 UTC about 1,100 prefixes were withdrawn. Cloudflare puts that at roughly 25% of its 4,306 BYOIP prefixes. For the customers affected, traffic to those addresses simply stopped arriving: the core CDN and security services, Spectrum, Dedicated Egress and Magic Transit were all hit for those ranges. The 1.1.1.1 website returned errors, though DNS resolution itself was unaffected.

An engineer stopped the process at 18:46. Around 800 prefixes were restored at about 20:20 UTC, and the remainder had to be rebuilt manually, finishing at 23:03 UTC.

Cloudflare was explicit that this was not an attack. It closed the post with a plain apology: “We let you down today.”

Why staging didn’t catch it

The change had been tested, but against mock data that never exercised the empty-value case. That is the uncomfortable part for the rest of us: the bug lives in the gap between “the filter is missing” and “the filter is empty”, a distinction that is easy to lose in serialization, ORMs and query builders.

Cloudflare’s own timeline is also a reminder that incident numbers are hard. The post gives a total duration of 6 hours 7 minutes, but its timeline works out closer to five hours from first impact. We report the timeline.

The fixes, and what to steal from them

Cloudflare listed four changes. Each is worth copying if you run anything that deletes things automatically:

  • Typed, validated flags. An API that deletes resources should reject an ambiguous or empty selector instead of defaulting to “all”.
  • Separate state from configuration. Operational bookkeeping (what is pending deletion) should not live in the same records as what customers configured.
  • Health-monitored rollouts. Ship destructive automation gradually and watch real signals, not just whether the job finished.
  • A circuit breaker. If a job is withdrawing or deleting far more, or far faster, than normal, it should stop itself and page a human.

Why it matters

If your product depends on a CDN, this incident is a good prompt to check what happens when a whole IP range disappears for a few hours. If you write internal tooling, it is a better one: search your codebase for any “delete where” built from a value that could be blank.

Sources

  1. Cloudflare: Cloudflare outage on February 20, 2026 (post-mortem, Feb 21, 2026)
  2. Cloudflare status page

We link every claim to the reporting or official statement it comes from. Where a detail rests on one outlet’s reporting, we say so. Spotted an error? Reply to any newsletter and we’ll correct it.