Major outages and post-mortemsBackground
Cloudflare outage on February 20, 2026 withdraws customer IP ranges for six hours
From 17:56 to 23:03 UTC (12:56 to 6:03 p.m. EST) on February 20, 2026, a buggy cleanup task at Cloudflare withdrew about 1,100 Bring Your Own IP prefixes, around a quarter of the total. Services using those addresses, which can include company VPN gateways and remote-access portals, could not be reached from any internet connection. The 1.1.1.1 resolver kept answering DNS queries; only its website showed errors. Published October 6, 2026.
- Event date
- Published here
- Updated
- Source
- Cloudflare blog
Background itemThis happened 228 days before we published it (more than 90). It is here as context for the guides it links, not as breaking news. Check the source for anything that has changed since.
What changed
On February 20, 2026, Cloudflare accidentally withdrew about 1,100 customer IP address ranges from the internet, around a quarter of all the ranges customers had brought to its “Bring Your Own IP” (BYOIP) service. For about six hours, services using those addresses could not be reached.
Cloudflare’s post-mortem says a buggy automated task, meant to remove ranges marked for deletion, queried its own API wrongly and treated every range as a deletion candidate. Cloudflare wrote: “This issue was caused by a change that Cloudflare made to how our network manages IP addresses onboarded through the BYOIP pipeline.” Most of the six hours went into restoring the configuration for each affected range.
Affected Cloudflare products included its core CDN and security services, Spectrum, Dedicated Egress and Magic Transit. The website for Cloudflare’s 1.1.1.1 resolver returned errors, but Cloudflare said DNS resolution itself was not affected.
When
- Start: 17:56 UTC on February 20, 2026 (12:56 p.m. EST).
- End: 23:03 UTC (6:03 p.m. EST).
- Duration: about 6 hours. Cloudflare published its post-mortem on February 21.
Who is affected and what it means for you
BYOIP is used by larger organizations that own their own IP addresses and route them through Cloudflare. Those can include the addresses of company VPN gateways, remote-access portals and customer-facing apps. If your employer’s gateway was on one of the withdrawn ranges, you couldn’t connect from home, from the office or from a phone.
For remote workers on Starlink, this is easy to misread as a VPN-versus-CGNAT problem, because CGNAT really does break some VPN types. The tell is that the VPN worked yesterday, nothing changed at home, and colleagues on cable and fiber are locked out too. Our VPN guide lists which VPN types struggle behind CGNAT, so you can rule that in or out quickly.
A backup internet line would not have helped: the destination was unreachable from everywhere.
What you can do now
- When the work VPN fails, ask in your team chat (on your phone if needed) whether others are affected before you troubleshoot the dish.
- Check your link in the Starlink app. If it’s healthy and other sites load, the problem is at the far end.
- Ask IT whether your remote-access gateway depends on a single provider, and what the fallback is.
- Our troubleshooting page covers the failures that really are on your side.
What stays the same
- Starlink’s network was not involved.
- 1.1.1.1 kept resolving DNS during this incident, per Cloudflare.
What we don’t know yet
- Which organizations were affected; Cloudflare doesn’t name customers.
- Whether Cloudflare’s resilience plan, which it said in May 2026 was complete, will prevent similar mistakes. We’ll note any later post-mortems.
This item is background: it happened more than 90 days before we published this page.
Source
Related guides on this site
Correction log
No corrections since publication. Spotted an error? See corrections for how to tell us; changes are logged here with the date.