Cloudflare outage on February 20, 2026
Authors: David Tuber, Dzevad Trumic
Overview
On February 20, 2026, at 17:48 UTC, Cloudflare experienced a significant service disruption affecting customers using its Bring Your Own IP (BYOIP) service. The incident involved unintentional withdrawal of BGP routes, making services unreachable for a subset of customers. The outage lasted 6 hours and 7 minutes, with approximately 1,100 BYOIP prefixes affected out of 4,306 total BYOIP prefixes globally.
The company clarified that the incident “was not caused, directly or indirectly, by a cyberattack or malicious activity of any kind.”
Impact on Customers
The incident resulted in varying levels of service disruption depending on product usage:
| Service/Product | Impact Description |
|---|---|
| Core CDN and Security Services | Traffic was not attracted to Cloudflare, and users connecting to websites advertised on those ranges would have seen failures to connect |
| Spectrum | Spectrum apps on BYOIP failed to proxy traffic due to traffic not being attracted to Cloudflare |
| Dedicated Egress | Customers leveraging BYOIP or Dedicated IPs for CDN Egress would not have been able to send traffic to their destinations |
| Magic Transit | End users connecting to applications protected by Magic Transit would not have been advertised on the Internet, and would have seen connection timeouts and failures |
Additionally, visitors to one.one.one.one encountered HTTP 403 errors with an “Edge IP Restricted” message, though DNS resolution over the 1.1.1.1 Public Resolver remained functional.
Affected customers initially experienced BGP Path Hunting behavior, where end user connections traverse networks trying to find a route to the destination IP. This persisted until connections timed out.
Root Cause
The incident stemmed from an automated cleanup process designed to remove BYOIP prefixes from Cloudflare’s network. The problematic code contained a bug in how it queried the API:
resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)The API implementation interpreted an empty string value for the pending_delete parameter as a request for all BYOIP prefixes rather than only those marked for deletion. As a result, the system began systematically deleting all BYOIP prefixes and their dependent objects, including service bindings.
The change had been merged on February 5, 2026, and deployed on February 20 at 17:46 UTC — just minutes before the impact became visible.
Why Testing Failed
Testing proved insufficient because the staging environment “was not sufficient in this case and the mock data we relied on to simulate what would occur was insufficient.” Coverage gaps existed around the scenario where the task-runner service would independently execute changes to user data without explicit input. Testing focused on the customer-facing self-service API journey but did not account for automated background processes acting independently.
Recovery Challenges
Recovery was complicated because affected prefixes existed in different states:
- Withdrawn only: Customers could toggle advertisements in the dashboard to restore service
- Withdrawn with partial bindings removed: Customers could toggle some but not all prefixes
- Withdrawn with all bindings removed: Customers could not toggle prefixes without manual intervention, requiring global configuration updates to restore service bindings across Cloudflare’s entire edge network
The incident revealed that operational state was tightly coupled with customer configuration in the same database, making rollback processes difficult.
Timeline of Events
| Time (UTC) | Status | Description |
|---|---|---|
| 2026-02-05 21:53 | Code merged | Broken sub-process merged into code base |
| 2026-02-20 17:46 | Code deployed | Address API release with broken sub-process completes |
| 2026-02-20 17:56 | Impact Start | Broken sub-process begins executing; prefix withdrawals begin |
| 2026-02-20 18:13 | Cloudflare engaged | Failures on one.one.one.one detected |
| 2026-02-20 18:18 | Internal incident declared | Engineers begin investigation |
| 2026-02-20 18:21 | Addressing API team paged | Engineering team engaged for debugging |
| 2026-02-20 18:46 | Issue identified | Broken sub-process terminated; remediation begins |
| 2026-02-20 19:11 | Mitigation begins | Engineers begin restoring withdrawn and removed prefixes |
| 2026-02-20 19:19 | Some prefixes mitigated | Customers begin re-advertising prefixes via dashboard |
| 2026-02-20 19:44 | Additional mitigation continues | Database recovery methods initiated |
| 2026-02-20 20:30 | Final mitigation process begins | Global configuration update deployment starts |
| 2026-02-20 21:08 | Configuration update deploys | Global machine configuration rollout begins |
| 2026-02-20 23:03 | Configuration update completed | Remaining prefixes restored; impact ends |
Remediation Steps
API Schema Standardization
Cloudflare will improve API schema design to prevent ambiguous parameter interpretation. The pending_delete flag will be standardized to ensure both client and server can properly validate API calls.
Better Separation Between Operational and Configured State
The company plans to redesign its database architecture to separate customer configuration from operational state. Future changes will be applied as snapshots through health-mediated deployments, similar to software releases. This approach enables quick rollbacks without requiring database snapshots during incidents.
Better Arbitration of Large Withdrawal Actions
Cloudflare will implement monitoring to detect rapid or broad changes, such as mass prefix withdrawals. A circuit breaker mechanism will halt deployments when changes occur too quickly or broadly. The system will also monitor customer service behavior to detect problems and stop potentially dangerous changes.
Code Orange: Fail Small Context
This incident occurred during implementation of the Code Orange: Fail Small initiative, aimed at improving infrastructure resilience through controlled rollouts of configuration changes. The change that caused the outage was intended to automate a manual process — removing BYOIP prefixes — as part of this safety improvement effort.
The company stated: “While this outage wasn’t itself global, the blast radius and impact were unacceptably large, further reinforcing Code Orange: Fail Small as a priority.”
Conclusion
Cloudflare acknowledged responsibility, stating: “We are sorry for the impact to our customers. We let you down today.” The company emphasized that the incident demonstrates the need for more robust safeguards around configuration changes that affect network operations, particularly automated processes that operate without explicit customer action.