When Cloudflare Is Down: Why “Internet Is Down” Is Not a Strategy

People say “if Cloudflare is down, the internet is down.” That instinct is understandable, but it hides the details that matter when you design for resilience.

You care about three layers. DNS answers “where is my site.” The edge is your proxy, WAF, CDN, and logic at the perimeter. The origin is where your application or static site actually lives, usually in a specific cloud region. Cloudflare can sit in one, two, or all three of those roles, depending on how you have deployed it.

When a major incident happens it may be purely DNS, or purely edge, or a routing issue between networks, or a mix of them. If Cloudflare is both your DNS provider and your proxy, you have bundled a lot of risk into a single vendor. When they hiccup you have no independent lever to pull. The first mindset shift is to treat providers like Cloudflare as powerful layers, not as your only layer.

There is another side to this. It is honest and it matters for your roadmap.

If a truly global Cloudflare outage happens today, many things break at once. SaaS tools, APIs, and customer sites your users rely on will all be impaired. Users and executives are annoyed, but they recognize it as a platform event. Your brand is not singled out in the same way it is when only you are dark on an otherwise normal Tuesday.

For simple marketing sites that reality matters. You should not contort your stack around a once in a few years global provider outage. You will get more value from fixing day to day availability, latency, and security issues. Where this logic breaks down is exactly where Define Gravity tends to live: regulated services, critical SaaS front doors, logins, public sector, and launch events where tens of thousands of people show up at once.

You do not fix this with a clever hack. You fix it with a small number of intentional patterns.

First, separate DNS from the edge for anything that matters. Use a dedicated DNS provider or at least treat DNS as a separate concern. Use Cloudflare for what it is great at: edge, WAF, caching, Workers or Pages. That way DNS stays under your control even if the proxy path has trouble.

Second, add a second path only where it pays off. For high stakes properties, add a second origin or a second region and a simple failover pattern. For lower stakes sites, accept that Cloudflare alone is enough, but write that down as a conscious decision. Complexity is cost and complexity is its own failure mode; you only reach for it when the business impact and regulatory posture justify it.

Third, prove it. Run failover drills. Break things in controlled ways using tools like chaos testing in Kubernetes. Make sure that when something fails your team is not learning in production. For the deep multi-region story, see The Multi-Region Mandate. For the launch and spike story, see Surviving the Thundering Herd.

The same principles apply whether you run a static brochure site or a banking front door. The implementation detail and level of investment change.

For a basic static site, a reasonable pattern is a domain at a registrar, DNS on Cloudflare, and the site on Cloudflare Pages or another static host behind Cloudflare. If Cloudflare has a regional issue, your site may still be fine. If Cloudflare has a global issue, your site likely goes with it. For many small businesses this is acceptable and the value from the free tier outweighs the downside.

For a high stakes static front door, you add a bit more structure. Authoritative DNS moves to a provider that supports health checks and failover. Cloudflare runs as a proxy in front of your primary origin. A secondary origin in another provider or region holds a mirrored copy. DNS health checks know how to route around an unhealthy origin or an unhealthy edge path. The user still visits the same domain and sees the same TLS identity; the complexity lives behind the curtain.

For dynamic applications the patterns are richer, but the idea is the same. You separate DNS from edge, edge from origin, and origin from the database layer instead of letting a single vendor sit across them all with no fallback.

You do not have to jump straight from shared hosting to a fully multi-region, multi-provider stack. You can treat this as a roadmap.

Start by writing down where you are today. Who runs your DNS. Who runs your edge. Where your origin runs. Whether those are the same vendor. Name one or two properties that matter more than the rest: a login page, a billing portal, a launch site. For each one ask how many minutes of downtime you can tolerate, what you would actually do in a provider outage, and whether that is written down and tested.

Take one small step. Move DNS for that property off the edge provider so you are not locked in. Add a second origin and test a manual failover. Run one controlled failover drill in a quiet window. If you never do more than that you are already ahead of most teams. If your risk and revenue grow this gives you a foundation to do the deeper multi-region and thundering herd work later without starting from zero.

Cloudflare is not the enemy. Blind dependence is. Reach out to discuss how to treat providers like Cloudflare as powerful layers in a resilient system instead of single points of failure.

Back to Perspectives