CLOUD CONCEPT
Νερατζιωτίσσης 15, Μαρούσι, Αθήνα, 15124, Αττική
+30 210 600 7072
info@c2.gr
On 18 November 2025, starting around 11:20 UTC, Cloudflare’s network began having serious trouble delivering traffic to its customers. If you tried to access a website behind Cloudflare around that time, you likely saw a “500-series” error page (a generic server error).
Here’s what went wrong, in plain language:
A change was made to a database permission system, which inadvertently caused a “feature file” used by Cloudflare’s bot-management system to double in size.
This feature file is pushed out to many machines (servers) across Cloudflare’s network. Because it was much larger than expected, many of those servers couldn’t handle it.
As a result, the network software that routes traffic hit a limit and started failing — leading to lots of sites inaccessible for a period.
Initially the team thought it might be some kind of large cyberattack (a DDoS), but this turned out to be an internal configuration issue, not malicious activity.
Here’s a breakdown of what users and customers experienced:
Cloudflare’s content delivery network (CDN) and standard security services showed high levels of 5xx errors (server errors).
The “Dashboard” (where customers manage their settings) also was impacted: while mostly visible, users often couldn’t log in because the login system depended on a service that was also failing.
Other systems such as “Workers KV” (Cloudflare’s key-value storage) and “Access” (their application access/authentication product) also had elevated error rates or failures.
11:05 UTC — The database permission change went live.
11:28 UTC — Traffic errors started to be observed by users.
13:05 UTC — A major mitigation step: Workers KV and Access were bypassed to reduce the impact.
14:30 UTC — The bad feature file had been replaced and global deployment started. Things began returning to normal.
17:06 UTC — All services were restored and functioning normally again.
Even if you’re not a tech person, outages like this matter because:
They show how complex modern internet infrastructure has become — a seemingly minor change in one component (a database query) can cascade into a large outage.
If your website or web app uses a service like Cloudflare (or you rely on a website and it fails), you may be affected even though the root cause isn’t obvious.
From a business or compliance perspective, such outages highlight the importance of resilience, monitoring, and planning for failure—even when the systems are highly professional.
If you’re managing your own site or relying on providers, this is a reminder to have a backup plan, monitor your status pages, and know how to respond when your service provider suffers an incident.
Cloudflare says it’s taking a number of steps:
Hardening the system that ingests configuration / feature files, treating them more like external inputs to make them safer.
Creating more global “kill-switches” for features, so if something goes wrong it can be shut down more quickly.
Reviewing all error and failure modes of their core proxy system (the part that routes traffic) so they better understand what might go wrong, and reduce the risk of large cascading failures.
A seemingly routine configuration change triggered a big outage affecting global traffic through Cloudflare.
The problem was internal (not an attack) but it still had wide-ranging effects because of how interconnected services are.
If you use cloud or internet infrastructure, this kind of incident underlines the importance of resilience, backups and awareness of your dependencies.
Cloudflare is treating the incident seriously and implementing measures to avoid similar failures in future.
In C2, responding to customer request to develop a highly redundant topology that will be able to recover in case of CDN failure by using redundant DNS providers and redundant CDNs. For more information you may contact us and discuss with an engineer.
If want want to read a more in depth analysis you can visit Cloudfare's Blog Post