On November 18, 2025, Cloudflare's network experienced significant failures that affected a large number of websites globally. Starting at 11:20 UTC, users trying to visit sites saw error pages, showing a failure within Cloudflare's own network. This deeply painful outage caused core traffic to stop flowing.
If you don't know already, here's what happened to Cloudflare on November 18, 2025.
Table of Contents
The Real Cause: A File That Got Too Big
First, let's be absolutely clear: A cyber attack or malicious activity did not cause this issue.
Instead, a seemingly small change inside Cloudflare's systems triggered the outage. The company was updating one of its database systems to improve security related to permissions.
Cloudflare uses a tool called the Bot Management system to protect sites from bad automated traffic. This system needs a detailed instruction list, known internally as a "feature file".
The permissions change caused a specific database process to start putting duplicate, unnecessary entries into this important file. Consequently, the feature file more than doubled in size.
Cloudflare confirmed that this problem came from inside their systems, not from attackers.
The Big Crash: Exceeding the Limit
Cloudflare rapidly sends this feature file to all the machines that make up its vast network. The software running on these machines routes all the Internet traffic.
Here is the key point: This traffic-routing software had a hard limit on the feature file size. Because the updated file was too large and exceeded this internal limit, the software failed immediately. This failure resulted in the network delivering widespread HTTP 500 error code to Internet users.
As mentioned in the Cloudflare blog post, the memory limit was set at 200 features, yet the system usually only uses about 60 features. The code then hit this capacity limit and failed due to an unhandled error. The code essentially asserted that this failure should never happen.
Why the Problem Came and Went (At First)
Initially, the outage symptoms looked very strange. The error volume kept fluctuating—the system would fail, and then it would recover for a short period. This unusual behavior made the team initially suspect a hyper-scale DDoS attack was occurring.
The database update was rolling out gradually. The system generating the feature file runs every five minutes. Because of the partial rollout, the query sometimes ran on an updated database part (producing a bad file) and sometimes ran on an older part (producing a good file). This constant switching back and forth caused the entire system to recover and then fail again.
To make matters worse, Cloudflare's external status page also went down at that time, which was a coincidence. This led some staff to believe an attacker was targeting multiple systems.
Which Other Services Failed?
The crash in the core proxy system affected many other important Cloudflare products.
- Core CDN and Security Services delivered 5xx status codes.
- Workers KV (a data storage service) saw a significantly elevated level of 5xx errors.
- Cloudflare Access experienced widespread authentication failures, meaning most users could not log in.
- The Dashboard was operational, but most users could not log in because the Turnstile security service failed.
Teams later reduced the impact on Workers KV and other systems like Access by implementing a patch at 13:05 UTC. This patch allowed Workers KV to bypass the core proxy system.
How Cloudflare Fixed It
The Cloudflare team finally identified the bad Bot Management configuration file as the trigger. They stopped the generation and propagation of the bad file at 14:24 UTC.
They then manually deployed an earlier, known good version of the feature file globally. By 14:30 UTC, core traffic was mostly flowing normally. The team spent the next few hours managing increased network load as traffic rushed back online. All systems were completely functioning normally by 17:06 UTC.
Cloudflare recognizes that any outage is unacceptable because of its importance to the Internet. Matthew Prince, Co-founder & CEO of Cloudflare, apologized for this unfortunate incident and assured this won't happen again.
The team is now hardening systems to prevent similar failures. For example, they are reviewing how they handle Cloudflare-generated configuration files, treating them with the same caution as user-generated input.
The Full Timeline: Cloudflare Outage November 18, 2025
11:05 UTC: The change begins
Cloudflare deploys a ClickHouse permission change that affects metadata visibility.
11:20 UTC: The bad file appears
The feature-file generator produces a larger file with duplicate entries. This begins to spread to edge proxies.
11:30–13:05 UTC: Outage intensifies
Proxies crash when they load the oversized file. Workers, Access, and other Cloudflare tools show high error rates.
13:05 UTC: Early mitigation
Cloudflare reduces failure impact on Workers and Access while debugging.
14:24–14:30 UTC: Fix deployed
Cloudflare stops generating new feature files. They push a known-good file across the network. Proxies begin to stabilize.
17:06 UTC: Full recovery
Traffic returns to normal levels. Cloudflare confirms the root cause and rules out an attack.
Conclusion
The Cloudflare outage on November 18, 2025 happened because a small database change triggered a hidden bug in the system. This caused a key file to grow too large and crash the proxy software across the network.
Cloudflare diagnosed the issue fast, fixed the root cause, and shared a detailed breakdown that helps everyone understand what went wrong.
This event reminds us how a tiny internal change inside an important internet company can affect millions of users at once.
