On 18 November 2025, a major Cloudflare outage briefly broke large parts of the internet. Users saw 5xx errors, apps refused to load, and big names like X (Twitter), ChatGPT, Canva, Shopify, Dropbox, Coinbase, and several transit systems all struggled at the same time.
Cloudflare later confirmed it was not a cyberattack, but a technical bug triggered by a routine change.
This post walks through:
- What Cloudflare is and why its outages matter
- What happened during the Cloudflare outage on 18 November 2025
- Which services and businesses were affected
- The technical root cause behind the Cloudflare issues
- How Cloudflare responded and what they plan to fix
- Practical lessons to reduce your risk from future CDN problems and internet downtime
1. What Is Cloudflare and Why Its Outages Matter
Cloudflare is a global content delivery network (CDN) and security provider that sits between websites and their visitors. It:
- Speeds up websites by caching content close to users
- Protects sites from DDoS and other attacks
- Provides DNS, firewall, bot protection, access control, and more
Roughly 20% of global web traffic is estimated to pass through Cloudflare’s infrastructure, so any Cloudflare outage can create a global outage ripple across thousands of services simultaneously.
2. Timeline of the November 18, 2025 Cloudflare Outage
Cloudflare’s own post-mortem and multiple news outlets give a fairly consistent timeline:
- 11:05 UTC – A change to the database permissions on a ClickHouse cluster is deployed inside Cloudflare.
- 11:20 UTC (approx.) – Cloudflare’s network starts to fail to deliver some core traffic. Users begin seeing Cloudflare-branded 5xx error pages.
- 11:30–13:05 UTC – Internal teams investigate. At first they suspect an attack or issues with Workers KV (a key-value storage service).
- Around 13:05 UTC – Cloudflare bypasses some internal dependencies (like Workers KV and Access) to reduce impact.
- Around 14:30 UTC – The root cause is identified and a fix is deployed by stopping the bad configuration file from propagating and rolling back to a known good version. Core HTTP traffic starts to normalize.
- By ~17:06 UTC – Cloudflare reports all systems as operating normally, with remaining services restarted and error rates back to standard baselines.
From a user perspective, the most visible internet downtime lasted a few hours, with a long “tail” of smaller issues as systems recovered.
also read: Massive Gmail Breach: What 2.5 Billion Users Need to Do Right Now
3. Which Services Were Affected?
Because Cloudflare sits in front of so many sites, the global outage appeared chaotic. Different platforms failed in different ways, but many of the names were high-profile:
3.1 Social and communication platforms
- X (Twitter) – Users saw internal server errors and loading failures.
- Some collaboration and communication tools like Zoom and Microsoft Teams were reported as having issues in certain regions.
3.2 AI and developer platforms
- ChatGPT, Claude, Perplexity, and other AI tools showed Cloudflare 5xx errors or messages like “please unblock challenges.cloudflare.com to proceed,” when Cloudflare’s challenge system failed to load correctly.
3.3 E-commerce, payments, and SaaS
Reports and outage trackers highlighted problems for:
- Shopify, Dropbox, PayPal, Coinbase
- Various business SaaS platforms like Sage and other enterprise services
3.4 Gaming and entertainment
Gamers saw login or connection failures on titles such as:
- League of Legends
- Genshin Impact
- Honkai: Star Rail
3.5 Public services and transit
Cloudflare’s role in critical public websites also became obvious:
- NJ Transit (US) and SNCF (France) reported issues with their sites and apps.
- Some public sector portals and city services saw degraded access, though core emergency systems generally remained unaffected.
In many cases, problems were limited to websites and apps that used Cloudflare’s CDN and security layer. Some underlying APIs and back-end systems remained healthy, but users couldn’t reach them because requests failed at the edge.
4. What Actually Went Wrong? (Technical Deep Dive)
The root cause of the Cloudflare outage was a chain reaction involving:
- A database permissions change
- A feature configuration file for Cloudflare’s Bot Management
- A size limit in the core proxy (FL/FL2) that wasn’t designed to handle the new file size
Cloudflare explained this in detail in their incident report.
4.1 Bot Management and the “feature file”
Cloudflare’s Bot Management system evaluates each HTTP request to decide whether it’s likely from a human or a bot. To do this, it uses a feature configuration file — essentially a structured set of attributes and signals the model can look at.
Key points:
- The feature file is generated every few minutes.
- It’s distributed across Cloudflare’s global network so bot detection stays current.
- The proxy allocates memory for this feature list with an upper bound (a limit) to avoid excessive resource use.
4.2 A ClickHouse query change with unintended consequences
Internally, Cloudflare uses the ClickHouse database. On 18 November, they changed how access control worked for distributed queries, making underlying tables more visible to users of the system.
The feature file generation query:
- Expected to see table metadata from a single database schema
- After the change, started seeing metadata duplicated from another schema as well
- As a result, the system generated a feature file containing many more features than normal (including duplicates)
This unexpected growth in the feature file size was the heart of the problem.
4.3 Hitting a hard limit and crashing the core proxy
The Bot Management module has a maximum number of supported features (for performance and memory reasons). At runtime:
- The proxy pre-allocates memory for up to that feature limit (e.g., 200 features)
- The new, enlarged feature file exceeded that limit
- When the module tried to load the file, it hit the limit and triggered a panic in the core Rust-based proxy code (the FL2 engine)
That panic translated into HTTP 5xx errors for traffic that depended on the bots module.
Because the feature file is automatically distributed across the network:
- Some edge locations loaded a valid feature file and worked normally
- Others loaded the oversized file and crashed
- Every few minutes, a newly generated file would propagate, sometimes good, sometimes bad
This led to a flapping pattern: services would recover temporarily, then fail again, making diagnosis harder.
4.4 Why it looked like an attack at first
At the same time:
- Error rates spiked
- Cloudflare’s own status page (hosted externally) briefly showed an error, which was a coincidence but increased suspicion of a coordinated incident
Given recent large-scale DDoS events on other platforms, engineers initially considered whether this was:
- A massive DDoS
- Or a targeted attack on both Cloudflare and its status page
Only after deeper inspection did they realize the “latent bug” was actually internal — triggered by an otherwise routine configuration change.
5. How Cloudflare Responded
5.1 Immediate mitigation
Cloudflare engineers took several steps as they realized this was an internal CDN problem, not an external attack:
- Stopped the generation and distribution of the faulty feature file
- Replaced it with a known good file
- Bypassed certain internal dependencies (like Workers KV and Access) in some paths to reduce impact
- Restarted affected services and nodes across the network
By early afternoon in the US, they reported that a fix had been implemented and that they believed the Cloudflare issues were resolved, though they kept monitoring.
5.2 Public communication
Cloudflare used:
- Their status page to post ongoing updates: Check Status of Cloudflare
- Social media (including posts from the CTO) to clarify that it was not a hack and to apologize
- A detailed incident blog post explaining the technical root cause once services stabilized
The CTO explicitly called it a failure on Cloudflare’s side, describing it as a latent bug triggered by a configuration change and apologizing for the impact on customers and the wider internet.
5.3 Long-term remediation steps
In their post-mortem, Cloudflare outlined how they plan to harden systems against similar CDN problems:
Planned improvements include:
- Treating Cloudflare-generated config files with the same strict validation as untrusted user input
- Adding more global “kill switches” to quickly disable problematic features
- Avoiding scenarios where crash dumps or debugging data can overwhelm resources
- Auditing failure modes across core proxy modules to reduce the risk that one module can knock out core traffic
They also described this as their worst outage since 2019, emphasizing that such a broad failure of core traffic is unacceptable and will drive architectural changes.
6. Impact on Users and Businesses
6.1 End users
For regular users, the Cloudflare outage mostly looked like:
- Pages taking a long time to load
- Browser messages like “500 Internal Server Error” or Cloudflare-branded error pages
- Apps failing to log in or timing out
Crucially, there was no evidence that user data was compromised; it was an availability issue, not a data breach.
6.2 Online businesses and SaaS providers
For businesses relying on Cloudflare, the internet downtime meant:
- Lost sales: storefronts and checkout pages became unavailable
- Support pressure: users flooded help desks and social media asking “Is your site down?”
- Operational delays: dashboards, internal admin tools, or APIs protected by Cloudflare Access also failed
This incident highlighted how a single vendor outage can impact:
- Front-end availability (users can’t reach the site)
- Authentication (Access failures)
- Security and observability pipelines
6.3 Developers and IT teams
For technical teams, the outage underlined:
- The risk of single-CDN dependence for critical traffic
- The importance of status monitoring and external checks to quickly distinguish local issues from global outages
- The need for clear incident communication to customers when the root cause is an upstream provider
7. Practical Lessons: Reducing Risk from Future Cloudflare Issues
Even if you’re not running Cloudflare infrastructure yourself, you can prepare for future global outages and CDN problems.
7.1 For businesses and site owners
- Consider multi-CDN or failover options
- Use more than one CDN provider for critical services when budget and complexity allow.
- At minimum, design your DNS strategy so that you can switch traffic away from a failing provider relatively quickly.
- Separate “must stay up” paths
- Keep essential APIs (e.g., payment confirmations, internal admin access) as simple as possible.
- Avoid chains where one failing module (like bot scoring) can block every critical request.
- Monitor from outside your stack
- Use third-party monitoring (multi-region, multi-network) to detect internet downtime and external dependencies failing.
- Keep uptime checks hitting your origin and through your Cloudflare edge, so you can see where the failure is.
- Have an incident playbook for upstream outages
- Pre-draft communications explaining that an upstream provider is experiencing issues.
- Decide when you will place banners on your site, pause campaigns, or switch to a “lite” version of the service.
- Review vendor SLAs and resilience posture
- Understand what your CDN, DNS, and hosting providers guarantee — and what they don’t.
- Periodically read incident reports (like this Cloudflare post-mortem) to see what failure modes you should plan for.
7.2 For individual users
When you see widespread Cloudflare errors or internet downtime:
- Check if it’s just you or global
- Look at a site’s own status page, Cloudflare Status, or independent outage trackers.
- Avoid unsafe “fixes”
- Don’t install random tools or browser extensions claiming to bypass Cloudflare or security checks.
- Be patient with services under load
- Once a large Cloudflare outage is resolved, there’s often a spike of catch-up traffic, so some apps remain slow for a while.
8. FAQ: Cloudflare Outage, Internet Downtime and CDN Problems
Q1. Was the November 2025 Cloudflare outage caused by a cyberattack?
No. Cloudflare, including its CTO, stated that the outage was due to a latent software bug in their infrastructure triggered by a routine configuration change, not by an attack.
Q2. How long did the Cloudflare outage last?
The most severe impact lasted roughly three hours, beginning around 11:20 UTC and easing after 14:30 UTC, with full normalization by around 17:06 UTC as remaining services were restarted.
Q3. Which websites and services were affected?
Many services relying on Cloudflare’s CDN and security layer were affected, including X (Twitter), ChatGPT, Canva, Perplexity, Shopify, Dropbox, Coinbase, major retailers, gaming platforms like League of Legends, and transit websites such as NJ Transit and SNCF, among others.
Q4. Did the Cloudflare outage compromise user data?
There is no evidence that user data was stolen or compromised. The incident was about availability (services not loading), not about data breach or unauthorized access.
Q5. How can businesses protect themselves from future CDN problems?
Key steps include using multi-CDN or failover options, monitoring services from multiple networks, keeping critical paths as simple as possible, and maintaining a clear incident response plan for upstream outages.
9. Conclusion
The November 18, 2025 Cloudflare outage is a textbook example of how:
- A small internal change (a database permissions update)
- Combined with a latent bug in configuration handling
- Can scale into a global outage affecting millions of users and thousands of businesses
It wasn’t a hack, but it was a serious reminder that internet infrastructure is highly interconnected. When a large CDN has Cloudflare issues, the effect is similar to a power grid failure for the web: many unrelated services go dark at once.
For businesses, the key takeaway is to design for failure — assume that providers like Cloudflare, AWS, Azure, or others will occasionally have outages, and plan your architecture, monitoring, and communication accordingly.
For users, it’s a reminder that sometimes, when “the whole internet feels broken,” the real problem is a single, very central layer — and it usually gets fixed quickly once identified.
