Cloudflare outage on February 20, 2026

What happened

On February 20, 2026, at 17:48 UTC, Cloudflare experienced a service outage affecting customers using the Bring Your Own IP (BYOIP) service. A subset of these customers saw their routes to the Internet withdrawn via Border Gateway Protocol (BGP). The incident was not caused by a cyberattack or any malicious activity — it was the result of a change Cloudflare made to how its network manages IP addresses onboarded through the BYOIP pipeline.

For affected BYOIP customers, services and applications became unreachable from the Internet, causing connection timeouts and failures. The website for Cloudflare’s recursive DNS resolver (1.1.1.1) returned HTTP 403 errors with an "Edge IP Restricted" message. DNS resolution over the 1.1.1.1 Public Resolver, including DNS over HTTPS, was not affected. The total incident duration was 6 hours and 7 minutes, with most of that time spent restoring prefix configurations to their pre-change state.

Cloudflare engineers reverted the change once failures were observed, but not before approximately 1,100 BYOIP prefixes were withdrawn. Out of 4,306 total BYOIP prefixes advertised globally, 25% were unintentionally withdrawn between 17:56 and 18:46 UTC. Some customers were able to restore service themselves by re-advertising their IP addresses through the Cloudflare dashboard. Around 20:20 UTC, Cloudflare reverted many advertisement changes, restoring 800 prefixes. The remaining ~300 prefixes could not be remediated through the dashboard due to a software bug that removed service configurations from the edge; engineers manually restored these at 23:03 UTC.

Affected customers first experienced BGP Path Hunting, where end user connections traverse networks attempting to find a route to the destination IP until the connection times out and fails. This failure mode affected any product using BYOIP for advertisement to the Internet.

Not all BYOIP customers were impacted because the configuration change was applied iteratively, not instantaneously. Once the change was revealed to be causing impact, it was reverted before all customers were affected.

How the Addressing API works

Cloudflare’s Addressing API is the authoritative dataset of addresses on the Cloudflare network. Any change to that dataset is immediately reflected in the global network. Customers configure IP addresses through public-facing APIs that update databases, triggering operational workflows that propagate changes to the edge.

The process of advertising and configuring IP addresses involves several steps:

• Customers signal advertisement/withdrawal of IP addresses via the Addressing API or BGP Control
• The Addressing API instructs machines to change prefix advertisements
• BGP is updated on routers once enough machines have received the notification
• Customers configure Cloudflare products to use BYOIP addresses via service bindings

While most processes are automated, some require manual actions. These manual processes carry risk due to their proximity to Production. As part of the Code Orange: Fail Small initiative, Cloudflare has been working to remove manual actions from the Addressing API and replace them with safe workflows.

Root cause

The broken change was a modification attempting to automate the customer action of removing prefixes from the BYOIP service — a regular request that was previously done manually. This automation was part of Code Orange: Fail Small work to push changes toward safe, health-mediated deployment. Because the list of related objects for BYOIP prefixes can be large, the change was implemented as a regularly running sub-task that checks for BYOIP prefixes marked for removal.

The cleanup sub-task queried the API with a bug:

 resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)

The relevant part of the API implementation:

	if v := req.URL.Query().Get("pending_delete"); v != "" {
		// ignore other behavior and fetch pending objects from the ip_prefixes_deleted table
		prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
		if err != nil {
			api.RenderError(ctx, w, ErrInternalError)
			return
		}

		api.Render(ctx, w, http.StatusOK, renderIPPrefixAPIResponse(prefixes, nil))
		return
	}

Because the client passed pending_delete with no value, the result of Query().Get("pending_delete") was an empty string (""). The API server interpreted this as a request for all BYOIP prefixes rather than only those marked for deletion. The system then treated all returned prefixes as queued for deletion, and the sub-task began systematically deleting all BYOIP prefixes and their dependent objects — including service bindings — until an engineer identified and shut down the sub-task.

Why testing didn't catch it

Cloudflare’s staging environment contains data matching Production as closely as possible, but it was insufficient in this case. The mock data used to simulate expected behavior did not cover this scenario. While tests for the BYOIP self-service API journey were completed successfully, testing did not cover a scenario where the task-runner service independently executed changes to user data without explicit input.

Why recovery wasn't immediate

Affected BYOIP prefixes were not all impacted in the same way, requiring different recovery actions:

• Most impacted customers only had prefixes withdrawn. These customers could use the dashboard to toggle advertisements and restore service.
• Some customers had prefixes withdrawn and some bindings removed. These customers were in a partial recovery state where they could toggle some prefixes but not others.
• Some customers had prefixes withdrawn and all service bindings removed. They could not toggle prefixes in the dashboard because no service (Magic Transit, Spectrum, CDN) was bound to them. These customers took longest to mitigate, as a global configuration update had to be initiated to reapply service bindings to every machine on Cloudflare’s edge.

As engineers reannounced prefixes to restore service, some customers may have seen increased latency and failures despite their IP addresses being advertised. This happened because addressing settings for some users were removed from edge servers due to a software bug, and state had to be propagated back to the edge.

Connection to Code Orange: Fail Small

The change that caused the incident was part of the Code Orange: Fail Small initiative, which aims to improve resiliency of code and configuration at Cloudflare. The work is divided into three buckets:

• Require controlled rollouts for any configuration change propagated to the network, similar to how software binary releases are handled today
• Change internal "break glass" procedures and remove circular dependencies so that systems remain accessible during incidents
• Review, improve, and test failure modes of all systems handling network traffic to ensure well-defined behavior under all conditions

The deployed change fell under the first bucket: moving risky, manual changes to safe, automated configuration updates deployed in a health-mediated manner. Critical work to enhance the Addressing API's configuration change support through staged test mediation and correctness checks was ongoing in parallel. Although preventative measures were not fully deployed before the outage, these systems were actively being worked on when the incident occurred. While this outage was not itself global, the blast radius and impact were unacceptably large, reinforcing Code Orange: Fail Small as a priority until confidence is re-established in all network changes being as gradual as possible.

Preventing a repeat: engineering changes after the outage

Standardizing API schemas

A key complication in this incident was that the pending_delete flag was being treated as a string, which made it hard for both clients and servers to consistently interpret its value. Cloudflare plans to tighten the API schema so that validating whether a call is correctly formed becomes straightforward for testing and automation. This effort belongs to the third Code Orange workstream, which focuses on defining predictable system behavior in every scenario.

Separating customer configuration from operational state

Currently, customer-driven changes to the addressing schema are written to the same authoritative database that handles operational actions. That design forces engineers to fall back on database snapshots during manual rollbacks, rather than comparing a desired state against the actual one. The remediation plan is to redesign both the rollback mechanism and the database structure so that quick reversions are possible, and to insert layers between customer configuration and what reaches Production.

The approach involves snapshotting the data read from the database before it is applied to Production, then deploying those snapshots through the same pipeline used for all other Production changes. Health checks would sit in that pipeline and be able to halt a deployment automatically if something goes wrong. With that in place, if the database is ever changed into a bad state again, Cloudflare could revert a single customer or the entire set of customers to a previously working version almost instantly.

During such an event, customers would temporarily lose the ability to update their settings through the API, but their traffic would continue to be served while the database is repaired. This work builds on the first and second Code Orange workstreams, which deal with fast rollback and health-mediated configuration deployment, respectively.

Circuit breakers for broad, rapid changes

Cloudflare will also improve monitoring to spot when changes are occurring too quickly or affecting too many systems, such as a rapid withdrawal or deletion of BGP prefixes. If that pattern is detected, the deployment of new snapshots would be disabled. The goal is a circuit breaker that keeps an out-of-control database process from causing a blast radius as wide as the one seen in this incident.

There is parallel work to directly monitor whether customer services are behaving correctly. Those signals could also trigger the same breaker, stopping potentially harmful changes until they can be investigated. This is part of the first Code Orange workstream, which covers safe deployment of changes.

Cloudflare has issued an apology for the outage and its impact on customers and the wider Internet. The company acknowledged that it fell short of its goal to keep the network resilient to change, and stated that the improvements described above are being made to ensure stability and to prevent a recurrence.