On Tuesday, November 18, 2025, Cloudflare’s network experienced a significant outage that affected multiple services and customers around the world. At Jerrejerre, as a company dedicated to developing and maintaining robust portals (Drupal, WordPress) and providing continuous technical support, we view these types of incidents as opportunities to reflect and reinforce best practices. In this post, we review what happened, why it matters, and how we can use this experience to strengthen the availability of our clients’ websites.
What happened?
We reviewed Cloudflare’s official incident report, and here is a brief summary of the timeline:
The incident began at 11:20 UTC on November 18, when Cloudflare’s network started experiencing failures in delivering traffic. Even though it was initially suspected to be caused by an external attack, no malicious activity was identified as the direct source of the problem.
The trigger was a permission change in one of their database systems (ClickHouse), which generated duplicates in a configuration “feature file” used by their Bot Management module. This file doubled in size, exceeded software limits on their proxy machines, and caused internal errors (HTTP 5xx) in the central proxy system.
There were erratic fluctuations: the faulty file propagated across different nodes, causing intermittent recovery and failure cycles, which made it harder to quickly identify the root cause.
Starting at approximately 14:30 UTC, Cloudflare began mitigating the issue: they stopped generating the faulty file, deployed a known good version, and restarted the central proxy. By 17:06 UTC, all systems were operating normally again.
Cloudflare described this outage as their worst since 2019, in terms of disruption to their core traffic infrastructure.
Why is this relevant for our clients?
As a provider of development, support, and maintenance for web portals (Drupal, WordPress), what happens to a global infrastructure provider like Cloudflare directly affects us for several reasons:
Availability and trust
Many of the websites we manage depend—directly or indirectly—on network services, CDNs, proxies, or security layers provided by Cloudflare. When those services fail, the end user sees an error page, performance degradation, or the site going offline. We have always trusted this system, and in our more than 10 years of experience, this has been the only major incident we’ve seen with this provider.
Managing external risks
Even with a well-designed architecture, there will always be external dependencies (infrastructure, DNS/CDN providers, caching services, etc.). This incident highlights that no provider is immune and that systems should be designed with failure scenarios in mind.
Client communication
When an event like this happens, the support team often receives the first calls from impacted customers. At Jerrejerre, we must be ready to explain what happened, outline our contingency plan, and clarify how we minimize exposure.
Operational responsibility
Our maintenance service goes beyond delivering a functioning portal: it includes monitoring, backups, dependency review, and recovery plans. Incidents like this reinforce the need for strong resilience policies.
Alternatives to Cloudflare
There are several services that offer protection, CDN capabilities, and attack mitigation similar to Cloudflare. Below is a useful comparison table for clients evaluating complementary or alternative providers:
| Provider | Main features | Approx. monthly cost | Comparison to Cloudflare Free |
|---|---|---|---|
| Cloudflare Free | Global CDN, basic WAF, fast DNS | $0 | — |
| Akamai | Very robust CDN, enterprise WAF, anti-DDoS | $200–$400+ | Much more expensive; enterprise-level |
| Fastly | Low-latency CDN, advanced VCL rules | $50–$150 | More flexible; moderate cost |
| Sucuri | WAF + CDN + malware monitoring | $25+ | Affordable and security-focused |
| Imperva | DDoS protection, advanced WAF, bot protection | $75–$200 | More advanced security than free CF |
| Bunny.net | Low-cost CDN, simple firewall | $1–$10 (usage-based) | Very affordable, great value |
| QUIC.cloud (WordPress) | CDN optimized for LiteSpeed Cache | $5–$30 | WordPress-optimized performance |
| Amazon CloudFront | AWS CDN, integrates with WAF and Shield | $20–$100 (usage-based) | Powerful but requires more setup |
Note: Prices vary depending on traffic, security rules, bandwidth, and additional features. These ranges reflect typical mid-size project usage.
What are we doing at Jerrejerre?
Ongoing evaluation and monitoring of critical external dependencies for every managed portal, including availability tracking.
Configuration of specific alerts to detect errors in CDN/WAF layers.
Documentation of contingency plans in case of external provider outages.
Advising clients who rely heavily on Cloudflare to assess whether they need redundancy or alternative solutions.
A full technical review of the incident to integrate lessons learned into our best practices.
Conclusion
The Cloudflare outage on November 18 reminds us that even the largest providers can experience significant failures. At Jerrejerre, we use these events to strengthen our mission: building resilient, monitored, secure systems ready to withstand unexpected disruptions.
If you would like us to review your external dependencies or help you configure redundancy or alternatives, we are ready to assist.
