Cloudflare / incident
Updated 15 Sep 2026

Cloudflare went down, too

Four Cloudflare postmortems show dependency, configuration and routing failures between June 2025 and February 2026.

Scope / Four incidents; product-specific, regional and broad network impact

The service protecting your edge can become the reason nobody reaches it.

Four incidents, four mechanisms

In June 2025, failure at a third-party storage provider made Workers KV unavailable and cascaded into Access, WARP, Turnstile, Workers AI, Pages and other products for two hours and 28 minutes.

In November, a database-permission change doubled the size of a Bot Management feature file. Propagating it across the network caused core traffic and dependent services to fail.

In December, a global configuration change exposed a long-hidden proxy bug. Cloudflare reported 25 minutes of errors affecting customers responsible for about 28% of the HTTP traffic it served.

In February 2026, Cloudflare unintentionally withdrew around 1,100 BYOIP prefixes. Some customer applications became unreachable during an incident that took six hours and seven minutes to fully resolve.

The boundary

No single one of these events took down every Cloudflare product for every customer. Their scopes and failure modes differed, and Cloudflare published detailed remediation work.

In May 2026, Cloudflare said its Code Orange “Fail Small” program had completed the configuration rollout controls that would have prevented the November and December global incidents. That materially changes the forward-looking risk; it does not erase the architectural lesson from the failures.

The point

An edge provider is a shared dependency. Outsourcing it does not outsource your exposure to its control-plane, storage and routing failures.

More incident dossiers

All cloud outage evidence → · Test your cloud exit readiness →