On 18 November 2025, Cloudflare experienced a significant global outage that affected traffic worldwide. At around 11:20 UTC, Cloudflare’s systems began failing to deliver core network traffic after an internal permissions change caused one of their Bot Management “feature files” to unexpectedly double in size. This oversized file exceeded capacity limits on edge machines, which in turn triggered routing software failures across large portions of Cloudflare’s global network.
As Cloudflare explains in their official blog post, this incident was not an attack, nor was it caused by malicious activity, instead it was the result of an operational change that cascaded into core traffic-handling services. Their dashboard, bot scoring, and certain edge-based functions were heavily affected, while their API remained far more stable throughout the incident. Cloudflare began rolling out a fix at around 14:30 UTC and fully restored normal traffic flow by 17:06 UTC.
What We Saw
Our monitoring systems detected unusual behavior earlier than the public announcement. At approximately 11:35 UTC, we began seeing widespread error spikes, elevated latency between Cloudflare edges and customer origin servers, and inconsistent behavior across Bot Management and WAF services. Because the symptoms were shared across many independent customer environments, our team quickly confirmed that this was not an origin issue, and instead was an upstream problem.
Although we identified the issue ahead of Cloudflare’s public notice at 11:48 UTC, we want to sincerely apologize. Our detection was early, but our alerting and customer support responses could have been faster. We should have moved more quickly to notify customers and begin coordinated mitigation, and we’re taking concrete steps to ensure this improves going forward.
How We Helped Customers Stay Online
Once we confirmed that Cloudflare’s global network was degrading, our team began working with affected customers to reduce downtime. Because Cloudflare’s API remained reachable throughout most of the incident (while the dashboard itself was failing), we were able to perform emergency changes for several of our Enterprise and Managed Cloudflare customers.
Where customers were not dependent on Cloudflare Origin Certificates, we temporarily disabled the Cloudflare proxy and routed their traffic directly to their origin servers. This allowed them to bypass the affected parts of Cloudflare’s edge network entirely while still keeping DNS resolution active. For many customers, this action restored stability until Cloudflare completed their fix and traffic normalized.
When Cloudflare reported that their network had returned to healthy operation, we re-enabled proxying, validated SSL behavior, and confirmed routing performance across all affected domains.
Improvements We Are Making
This outage highlighted the importance of being able to react instantly when an upstream provider experiences a catastrophic event. While our overall mitigation worked, we believe we can, and must, do better.
Here’s how we are improving:
A One-Click “Kill Switch” in Vigilbase One
We are adding a global control inside Vigilbase One that fully disables the Cloudflare proxy for any selected domain or customer profile. This will instantly switch services to DNS-only mode and route traffic directly to the origin without manual intervention. It means we can restore connectivity within seconds, not minutes.
Full Infrastructure Backups Using Terraform
Although many of our deployments already were using Terraform internally, by expanding our Terraform usage across all customers, we are able to quickly make changes across the board. We are implementing complete configuration backups, including:
- Full DNS zone files (BIND format)
- Full Cloudflare configuration bundles
- Version-controlled Terraform state and resources
If Cloudflare ever experiences a large-scale control-plane failure again, we will be able to modify and restore configurations far more quickly.
Enhanced Real-Time Monitoring with Flarehawk
We are integrating Flarehawk, our AI-driven traffic analytics engine, to automatically detect anomalies such as upstream routing instability, sudden error spikes, or sharp latency increases. These signals will be connected to automation triggers, including the new kill switch.
Faster, More Transparent Customer Alerts
We are updating our incident-response playbooks and communication protocols so that customers receive immediate notification when we detect upstream issues. Early detection must lead to early action, and we are redesigning our processes to guarantee that.
Closing Thoughts
The Cloudflare outage on November 18 was one of the more disruptive events in recent memory, and we recognize the impact it caused for many organizations around the world. We also recognize that although Vigilbase detected the issue early, our response could have been even faster, and for that, we apologize.
Cloudflare, like any other technology company, unfortunately is not immune to these types of incidents. Just like the recent Microsoft Azure and Amazon Web Services incidents, this shows the fragility of the world's internet, and our need, as a managed service provider, to take action quickly once our systems detect issues on upstream providers.
We are committed to learning from this incident and strengthening every layer of our monitoring, automation, and response capabilities. With the enhancements now underway, we will be better prepared to protect our customers against any future upstream disruptions.
If you have any questions regarding the outage, or how we will prevent future outages and incidents from affecting your infrastructure, contact our support team or your account team.
You can read more about the outage in The Cloudflare Blog.
Our affected services included:
- Cloudflare Enterprise
- Vigilbase Managed Cloudflare
- Vigilbase Shield
- Vigilbase One (customer dashboard)
- Flarehawk (customer dashboard)
Status incident reports:
