On 20 February 2026, Cloudflare had the sort of outage that looks narrow on paper but feels brutal to the customers caught inside it. A subset of customers using Cloudflare’s Bring Your Own IP, or BYOIP, service saw their routes to the Internet withdrawn through Border Gateway Protocol. In plain English: some customer-owned IP ranges stopped being advertised properly, so users on the Internet could no longer find the services behind them.
The incident lasted 6 hours and 7 minutes. Cloudflare said about 1,100 prefixes were withdrawn before engineers stopped the change. That represented 25% of the 4,306 BYOIP prefixes advertised to the peer Cloudflare used in its post-mortem analysis. Cloudflare was clear that this was not a cyberattack. It was caused by a change to how its network managed IP addresses onboarded through the BYOIP pipeline.
For executives, the tempting response is to file this under “provider outage” and move on. That would be a mistake. This was not only a Cloudflare story. It was a clean demonstration of how modern digital resilience can fail in the control plane, not the application stack.
BGP is boring until it becomes the business
Border Gateway Protocol is the Internet’s routing language. It tells networks which path to use to reach an IP address. Most business leaders never hear about it unless something goes wrong, which is precisely the problem. BGP is infrastructure plumbing, but when the plumbing is attached to customer journeys, revenue flows and public services, it becomes a business dependency.
BYOIP makes this dependency even more interesting. Companies bring IP ranges they own and allow a provider such as Cloudflare to advertise those addresses from its network. That can support performance, security and migration flexibility. It also means the organisation’s reachability depends on the correctness of a provider’s routing and configuration systems.
I once worked with a regional enterprise that had a beautifully resilient application stack: multi-zone deployment, replicated databases, tested failover and a polished disaster recovery document. Yet its customer portal still depended on a single external routing assumption nobody in the application team owned. When we asked who could explain the Internet path into the service, the room went quiet. That silence is where outages hide.
What actually happened
Cloudflare’s post-mortem says the outage began at 17:48 UTC on 20 February 2026. Some BYOIP customers saw routes withdrawn via BGP. For affected customers, services and applications using those BYOIP addresses became unreachable from the Internet, causing connection timeouts and failures. Cloudflare also said the website for its recursive DNS resolver, one.one.one.one, showed 403 errors, while DNS resolution through the 1.1.1.1 public resolver was not affected.
The root cause was a change intended to automate a manual customer action: removing prefixes from Cloudflare’s BYOIP service. Cloudflare had been working under its “Code Orange: Fail Small” programme, which aimed to reduce risky manual actions and push changes towards safer, automated, health-mediated deployment. The goal was sensible. The execution failed.
A cleanup sub-task queried an API with a bug. Because a parameter was passed without a value, the API interpreted the request too broadly. Instead of acting only on prefixes meant to be removed, the system treated all returned BYOIP prefixes as queued for deletion. The sub-task then began deleting BYOIP prefixes and related dependent objects, including service bindings, until engineers identified and stopped it.
That detail matters. The failure was not simply “someone made a bad change”. It was a mismatch between automation intent, API behaviour, test coverage and blast-radius control.
The dangerous middle state of recovery
One of the most useful parts of Cloudflare’s write-up is its description of different customer recovery states. Some customers only had prefixes withdrawn and could restore service by toggling advertisements in the Cloudflare dashboard. Others had prefixes withdrawn and some bindings removed. A third group had all service bindings removed, meaning they could not restore prefixes through the dashboard because there was no service such as Magic Transit, Spectrum or CDN bound to them.
This is the uncomfortable part of resilience that architecture diagrams usually hide. Systems rarely fail into one clean state. They fail into partial states. One customer can self-remediate. Another needs a provider engineer. A third sees routes return but still experiences latency or failures while configuration propagates back to edge servers.
The hard truth is that many incident playbooks assume binary states: up or down, primary or secondary, failed over or not. Real outages are messier. They involve inconsistent configuration, stale dependencies, partial restoration and customer-specific blast radii. If your resilience plan does not cover that middle state, it is more theatre than engineering.
Why “fail small” is the right idea, even when it fails
It would be easy to mock Cloudflare’s “Fail Small” language because this outage was not small for affected customers. That misses the lesson. The principle is exactly right: changes should roll out gradually, be observed continuously and stop automatically when they cross risk thresholds. The problem was that the necessary safeguards were not fully in production for this path.
Cloudflare said it was already working on safer configuration-change support, staged test mediation, better correctness checks and operational state snapshots. It also said future improvements would include redesigning rollback mechanisms, introducing layers between customer configuration and production, and improving monitoring to detect when changes happen too quickly or too broadly, such as rapid withdrawal or deletion of BGP prefixes.
Those commitments translate into a broader enterprise principle: automation without circuit breakers is just high-speed fragility. The more critical the workflow, the more the organisation needs controlled rollout, state validation, automatic halt conditions and a known-good rollback path.
I have seen automation programmes sold to boards as a way to remove human error. Frankly, that is incomplete. Automation removes some human errors and industrialises others. A manual mistake may affect one ticket. A poorly bounded automated task can affect hundreds of customers before the first alarm reaches the right engineer.
The enterprise checklist hidden in the incident
For CIOs, CISOs and infrastructure leaders, this outage should trigger a practical review of internet-facing resilience. Not a philosophical workshop. A hard-nosed dependency review.
Start with route ownership. If your organisation uses BYOIP, Magic Transit, CDN services, global traffic managers or managed DNS, name the internal owner for each route and prefix. Do not leave this knowledge trapped between a network engineer, a vendor portal and a renewal spreadsheet.
Next, test provider failover assumptions. If a route is withdrawn from one provider, where should traffic go? Can another provider advertise the prefix? Who is authorised to make that change? How long does propagation take? Which services are safe to fail over and which are tied to provider-specific controls?
Then examine blast-radius testing. A dangerous change should not be able to touch every prefix, every region or every customer binding at once. If your provider cannot explain staged rollout, rate limits, anomaly detection and rollback for configuration changes, you do not yet understand the resilience you are buying.
Finally, demand evidence. Status pages are useful, but they are not an operating model. Enterprises should ask for post-incident detail, recovery timelines, customer action guidance, and the provider’s specific engineering changes after major incidents. In regulated sectors, that evidence belongs in vendor-risk and operational-resilience records, not buried in an engineering Slack channel.
The APAC angle: resilience is now ecosystem governance
In Singapore and across APAC, digital services increasingly depend on a dense chain of cloud, CDN, DNS, identity, payment and security providers. A bank’s mobile app, a retailer’s checkout flow or a logistics platform may look like one digital product to customers. Underneath, it is an ecosystem of control planes.
That ecosystem model changes the job of technology leadership. Resilience is no longer only about whether your application servers can survive a zone failure. It is about whether third-party configuration systems, network announcements, certificates, identity providers and traffic controls can fail safely.
This is where procurement and architecture must meet. Vendor selection should not stop at performance charts and commercial discounts. It should ask how the provider changes production, how it limits blast radius, how it exposes operational state, and how customers can act during an incident. The cheapest provider can become expensive if your team cannot see or influence the failure mode.
What good resilience looks like now
A mature organisation should be able to answer five questions after reading Cloudflare’s post-mortem.
First, which public IP ranges, DNS zones, CDN configurations and traffic-management policies are critical to customer access? Second, which provider systems control them? Third, what happens if those controls make a bad change? Fourth, how quickly can the organisation detect whether customers are affected? Fifth, who has the authority, tooling and rehearsal history to act?
Notice that none of those questions are purely technical. They are about ownership, evidence and decision rights. That is why resilience has become a leadership discipline. The network team may understand BGP. The platform team may understand deployment. The vendor-risk team may understand contracts. But the customer experiences only one thing: the service is reachable, or it is not.
A useful exercise is to run a tabletop drill for route withdrawal. Assume a critical prefix disappears from the Internet for one hour. Do not start with root cause. Start with impact. Which customers call first? Which dashboards light up? Which executives are notified? Which provider contacts are used? What customer message goes out? What temporary controls are available? If the drill becomes confusing, the real incident will be worse.
Bottom line
Cloudflare’s February 2026 BYOIP outage is a reminder that digital resilience often fails in the quiet layers. Not in the shiny mobile app. Not in the database cluster everyone monitors. In the routing advertisement, configuration API, service binding or rollback mechanism that only a handful of specialists understand.
The lesson is not to distrust Cloudflare. Cloudflare’s detailed post-mortem is exactly the sort of transparency customers should expect from critical providers. The lesson is to stop treating internet reachability as someone else’s plumbing.
If your business depends on being reachable, routing is part of your product. If your customer experience depends on a provider’s control plane, that control plane is part of your risk register. And if your resilience plan cannot explain what happens when a prefix disappears, you do not yet have resilience. You have hope with a dashboard.