The Cloudflare outage of November 2025: one oversized file
A routine database change doubled the size of a configuration file, and a large part of the web returned errors for hours.
Kivorent News desk, published , 2 min read
This is a look back at an event from . We wrote it on November 11, 2026, from the sources listed at the end.
What to know
- Cloudflare's network began failing at 11:20 UTC on November 18, 2025.
- A database permission change caused a bot-detection configuration file to grow past a size limit, which crashed the software that routes traffic.
- It was not an attack. Traffic was largely restored by 14:30 UTC and fully by 17:06 UTC.
On the morning of November 18, 2025, websites and apps around the world started returning error pages. They had one thing in common: they sat behind Cloudflare, a company that handles traffic for a large share of the internet.
What happened
Cloudflare's chief executive, Matthew Prince, published an account the same day. This summary follows CircleID's report on it.
- Engineers changed permissions on a database.
- That change caused a query to return duplicate rows.
- The query's output was used to build a configuration file for Cloudflare's bot-detection system. With the duplicates, the file was much larger than normal.
- The software that reads the file had a fixed limit on its size. The new file exceeded it, and the software failed.
- That software sits in the path of ordinary traffic, so requests across the network began to fail.
The bad file was regenerated and pushed out every few minutes, so the network recovered and failed in waves. That pattern at first looked like a large attack. It was not.
The timeline
| Time, UTC | Event |
|---|---|
| 11:20 | Errors begin |
| 14:30 | Change rolled back, most traffic flowing |
| 17:06 | Full recovery confirmed |
Sign-in checks, data storage and access controls that depend on the same systems were affected too, which is why some people could not log in to services that were otherwise up.
What Cloudflare said it would change
Stricter validation of internally generated configuration files, treating them with the same suspicion as outside input, and better isolation so that one failing component cannot take down traffic routing.
Why it mattered
The outage came four weeks after a large Amazon Web Services failure. Together they made a point that is easy to forget: much of the web depends on a handful of companies, and an ordinary internal change at one of them can reach millions of people.
For anyone running a site, the practical lesson was to know which single providers your service cannot work without, and to decide in advance what your users see when one is down.
Sources
Spotted an error? Tell us and we will fix it.