Cloudflare Outage February 2026 Lessons

Key Takeaways:

• At 17:48 UTC on February 20, 2026, a Cloudflare internal change withdrew 1,100 BYOIP prefixes via BGP, taking 25% of its 4,306 BYOIP prefixes off the internet for 6 hours and 7 minutes.
• The trigger was a single API bug: a cleanup task called pending_delete with no value, and the server read the empty string as “delete every BYOIP prefix.”
• About 300 prefixes could not be fixed through the dashboard because their service bindings had already been deleted from the edge, forcing manual restoration at 23:03 UTC.
• Cloudflare’s own postmortem is the primary record; independent coverage confirms the timeline but adds little verification beyond it, so treat the vendor’s remediation promises as unproven until they ship.
• If you run BYOIP, the outage tested your own runbook, not Cloudflare’s. Multi-homing, independent route monitoring, and tested dashboard access are the controls that matter.

What Happened on February 20, 2026

At 17:48 UTC on February 20, 2026, Cloudflare experienced a service outage when a subset of customers using its Bring Your Own IP (BYOIP) service saw their routes to the internet withdrawn via Border Gateway Protocol (BGP). The company’s official postmortem states clearly that the issue was caused by a change Cloudflare made to how its network manages IP addresses onboarded through the BYOIP pipeline. It was not caused, directly or indirectly, by a cyberattack or malicious activity of any kind.

The incident lasted 6 hours and 7 minutes, according to Cloudflare’s incident report. Most of that time was spent restoring prefix configurations to their previous state rather than diagnosing the problem. Independent coverage from Cyber Security News confirms the same start time, duration, and root cause, and notes that 25 percent of all BYOIP prefixes globally were affected, with HTTP 403 errors appearing on the 1.1.1.1 public resolver website.

This was the third major Cloudflare incident in about three months. The November 18, 2025 outage began with a ClickHouse permissions change that inflated a Bot Management feature file past proxy limits, and the December 5, 2025 outage came from a WAF configuration toggle that surfaced a dormant rules-engine bug, returning 500s for roughly 25 minutes. All three incidents involved internal changes reaching production without safety measures sized to their impact, with no attacker or hardware failure involved.

How a Config Change Withdrew 1,100 Prefixes

The mechanism is important to understand because it is the kind of bug that can pass code review unnoticed. Cloudflare’s Addressing API is the authoritative dataset of addresses on its network, and any change to that dataset propagates to the edge immediately. To remove a manual step from the BYOIP offboarding process, engineers added a regularly running sub-task that checks for prefixes due for removal and deletes them.

That sub-task issued this request:

GET /v1/prefixes?pending_delete

The server-side handler read the flag with req.URL.Query().Get("pending_delete"). Because the client passed the parameter with no value, the result was an empty string, and the handler’s if v != "" check failed. The code fell through to the default path and returned every BYOIP prefix instead of only those pending deletion. The sub-task then treated the full result set as queued for removal and began deleting prefixes along with their dependent objects, including service bindings.

Between 17:56 and 18:46 UTC, 1,100 prefixes out of 6,500 advertised to a BGP peer were withdrawn. Out of 4,306 total BYOIP prefixes, 25 percent were pulled. The change was applied iteratively rather than all at once, which limited the impact: once issues appeared on one.one.one.one, engineers reverted the change before every customer was affected.

The user-visible failure mode was BGP path hunting. Instead of an immediate connection refusal, end-user connections kept traversing networks looking for a route to the destination IP, looping until the connection timed out. That is why the outage felt like slowness and intermittent failure rather than a clear error for many users. Cloudflare has written about this behavior before, and it is exactly what makes withdrawn-prefix incidents hard to diagnose from the application side.

Blast Radius: Which Products Broke

BYOIP is not a niche add-on. Any Cloudflare product that advertises customer-owned address space to the internet depends on it, so a prefix withdrawal takes down the whole service binding at once. Cloudflare’s own breakdown lists four product families affected, and the pattern is consistent: traffic did not reach Cloudflare’s network, so nothing downstream could work.

Separately, visitors to one.one.one.one, the website for Cloudflare’s recursive DNS resolver, received HTTP 403 errors and an “Edge IP Restricted” message. DNS resolution over the 1.1.1.1 public resolver, including DNS over HTTPS, continued to work. That distinction matters for incident triage: a 403 on the marketing page is not the same failure as broken resolution, and conflating them sends responders down the wrong path.

Cloudflare routes about 20 percent of global web traffic, as noted in CRN’s roundup of 2026 cloud outages. That concentration turns a routing mistake into a global event. The same CRN piece cites a Cisco Splunk report putting downtime costs for Global 2000 companies up 50 percent over two years, with an average of $300 million lost per year to unplanned outages and an average 3.4 percent stock price drop after a single incident. Splunk also attributes 43 percent of downtime events to network and IT environment issues, 30 percent to cybersecurity, and 24 percent to application or infrastructure failures. Network configuration errors are the largest category.

Recovery: Why Six Hours, Not Sixty Minutes

The interesting part of this incident is not the cause. Fixing it took 5 hours and 7 minutes after the broken process was stopped. The reason is that the 1,100 withdrawn prefixes were not in a uniform state, and each state needed a different remedy.

Most affected customers had only their prefixes withdrawn. Those customers could fix the problem by toggling their advertisements back on in the Cloudflare dashboard, and at 19:19 UTC Cloudflare published guidance telling them to do exactly that. A second group had prefixes withdrawn and some service bindings removed, so they could restore some prefixes but not others. A third group had prefixes withdrawn and all service bindings removed, which meant there was no service bound to the prefix and nothing to toggle. Those customers waited the longest, because restoring them required a global configuration update pushed to every machine on Cloudflare’s edge.

Cloudflare reverted many advertisement changes around 20:20 UTC, restoring 800 prefixes. The remaining roughly 300 were restored manually by engineers at 23:03 UTC, which is when the incident ended. The company’s postmortem is candid about the gap: the operational-state snapshot system that would have allowed a fast rollback to a known-good state was under construction as part of its Code Orange: Fail Small initiative but was not in production at the time.

One detail deserves attention for anyone planning recovery from a control-plane failure. The remediation path for the worst-affected customers ran through the Cloudflare dashboard. If the dashboard itself is degraded or the control plane is the problem, that path is not available. Cloudflare’s own Code Orange bucket two work is explicitly about removing circular dependencies in break-glass procedures so that both the company and its customers can act during an incident. That work was not finished either.

What Cloudflare Claims vs. What Independent Sources Confirm

The primary record for this incident is Cloudflare’s own postmortem. Independent outlets, including Cyber Security News, Stratusclear, and The Daily Tech Feed, largely restate the vendor’s account: the same 17:48 UTC start, the same 1,100 prefixes, the same 25 percent figure, the same 6-hour-7-minute duration, the same remediation list. That confirms the narrative, but does not independently verify the numbers. The prefix counts and the 25 percent figure come from Cloudflare and have no external measurement behind them.

The claims that need the most skepticism are forward-looking. Cloudflare says it will standardize the API schema so flags cannot be misinterpreted, add circuit breakers that detect abnormally fast BGP prefix deletion, and build health-mediated operational state snapshots that separate customer configuration from production rollouts. Each is a reasonable fix for the specific failure. None is live, and the postmortem says so: the snapshot system “is not in prod today,” and the staged test mediation for Addressing API changes was “ongoing in parallel” with the change that broke things.

There is also a structural criticism the vendor does not address. The February change was itself a Code Orange: Fail Small project, an attempt to remove a risky manual process by automating it. The automation introduced a worse failure than the manual process it replaced. That is a known hazard when you move a human check into a task runner without equivalent validation, and it argues for treating automation of production-mutating workflows as a change with its own blast-radius review, not as a reliability improvement by default.

Practitioner reviews point at a related pattern. PeerSpot’s Cloudflare pros and cons page, based on 80 reviews, lists among the cons that Cloudflare sometimes falsely indicates server downtime, making it harder to identify the real problem, and that pricing and technical support are weak points. A reviewer identified as M.A. Faisal, General Manager at bKash Limited, wrote in January 2026 that the organization had faced “a couple of incidents due to Cloudflare in recent years.” That is anecdotal, but it matches a three-incident quarter.

An SRE Playbook for BYOIP and Multi-CDN

If your production traffic depends on BYOIP through any provider, the February incident is a test you can run against your own setup. The controls that would have shortened your exposure are straightforward, and each has a real cost.

Multi-home your prefixes. Advertise critical address space through more than one provider or upstream so a single withdrawal does not remove your only path. The trade-off is real: multi-CDN introduces certificate management overhead, WAF policy synchronization across vendors, and a testing surface someone has to own. It is worth it for payment, identity, and revenue-critical paths. It is probably not worth it for a marketing site.

Monitor your routes independently. Do not rely on your provider’s status page to tell you your prefix is gone. Query public BGP looking glasses or a route-monitoring service from outside your primary provider’s network, and alert when a prefix stops being visible from major vantage points. The detection window in this incident was about 50 minutes from impact to root cause, which is fast for a provider but slow for a customer watching revenue.

Verify dashboard access before you need it. The self-remediation path here was a dashboard toggle. Confirm that your on-call engineers have working credentials, current MFA, and training for every provider whose console they might need at 3 a.m. A runbook step that assumes console access is untested until someone tries it under pressure.

Rehearse prefix withdrawal quarterly. Simulate a withdrawn prefix and time how long it takes to detect, escalate, and restore. Most teams test compute failover and never test network-layer failover, which is exactly the layer that failed here.

For teams comparing providers, the honest position is that no CDN or edge vendor publishes a BYOIP incident history that would let you rank them on this axis. Akamai, Fastly, and Cloudflare all offer edge compute and security, but only Cloudflare publishes postmortems at this level of technical detail. That transparency is useful and also a selection effect: you hear about Cloudflare’s config bugs because Cloudflare writes them up.

Troubleshooting a Prefix Withdrawal

When traffic to a BYOIP range starts failing with timeouts rather than immediate errors, work outward from the route.

• Check route visibility first. Query a public looking glass for your prefix from several regions. If it is absent from most, you have a withdrawal, not an application bug. Do not start with your origin servers.
• Distinguish path hunting from a hard failure. Timeouts and slow failures across many users point to a missing route. Connection refused usually points at the origin.
• Confirm service bindings. In Cloudflare’s case, prefixes with no bound service could not be toggled back on. Check whether the product binding (Magic Transit, Spectrum, CDN) still exists for the prefix before assuming a dashboard toggle will work.
• Check for the 403 signature. HTTP 403 with “Edge IP Restricted” on one.one.one.one appeared during this incident. It does not mean DNS resolution is broken; resolution over 1.1.1.1 continued to work.
• Escalate with specifics. Give your provider the exact prefix list, the first failure timestamp, and the looking-glass evidence. Prefix-level detail shortens the path to the right team.

One caveat on all of this: the remediation steps that worked in February were the ones Cloudflare published at 19:19 UTC, and they were dashboard-based. No CLI path was published for this incident. If a future incident degrades the dashboard, the documented path may not exist, which is why rehearsing the failure beats reading the runbook.

What to Change Before the Next One

The February 20, 2026 outage was a one-line API contract bug, a missing value where a value was required, that reached production inside an automation project meant to reduce risk. The fix list Cloudflare published is targeted and reasonable: schema standardization, circuit breakers on rapid prefix deletion, and health-mediated snapshots of operational state. The gap is that none of it was live when it was needed, and the same was true of the November and December 2025 incidents.

For infrastructure teams, the practical conclusion is that provider reliability is not a control you own. Prefix withdrawal, config poisoning, and control-plane failures happen at every large provider; you hear about Cloudflare’s because it publishes them. What you control is detection time, whether you have a second path, and whether your on-call engineers can actually execute the recovery steps at the moment they are needed. Treat the vendor’s postmortem as a free red-team report on your own architecture, and close the gaps it exposes before the next config change lands.

For related reading on operational risk and incident handling, see our coverage of vulnerability disclosure pitfalls and forensic source integrity workflows.

Sources: Cloudflare outage on February 20, 2026; Cyber Security News; Stratusclear; The Daily Tech Feed; CRN; PeerSpot; Cloudflare November 2025 postmortem; Cloudflare December 2025 postmortem.

Related Reading

More in-depth coverage from this blog on closely related topics:

• How to Speed Up Large Language Models
• EU AI Act Article 50 Disclosure Guide
• Moonshine Game Streaming Setup Guide
• Best Local AI Inference Tools for 2026
• Apple Silicon MacBook Accelerometer Guide

Sources and References

Sources cited while researching and writing this article:

• Cloudflare outage on February 20, 2026 | Cloudflare Blog
• Cloudflare Down – 6 Hour of Massive Global Service Outage Cause Customers Unreachable From the Internet
• November 18, 2025 outage
• Cloudflare outage on December 5, 2025 | Cloudflare Blog
• written about this behavior before
• The 10 Biggest Cloud Outages Of 2026 (So Far)
• Cloudflare outage on February 20, 2026 | Stratusclear.org
• Cloudflare Outage February 2026: Configuration Error Disrupts Global Internet Services – The Daily Tech Feed
• Cloudflare pros and cons page