On 18 November 2025, a single technical incident at Cloudflare was enough to make large parts of the internet feel “down” for hundreds of millions of people.

For a few hours, users trying to access platforms like X, ChatGPT, Spotify, Canva, Grindr and thousands of other sites were greeted with the same message: an “internal server error on Cloudflare’s network” and generic 500 pages instead of the services they rely on every day. Cloudflare, which handles roughly a fifth of global web traffic, reported a global network issue that led to widespread 500 errors and impacted its dashboard and API, before progressively deploying a fix and stabilising its infrastructure.

Incidents happen. Bugs exist. No system is perfect.

The real problem is that our entire digital ecosystem is now deeply dependent on a few infrastructural chokepoints – and most organisations don’t even have a clear map of those dependencies.

This is what I want to talk about here: not to point fingers at Cloudflare, but to use this outage as a concrete, global reminder of why resilience and digital dependency need to become first-class topics in every boardroom.

Cloudflare as a single point of failure

Cloudflare is doing what Cloudflare is supposed to do: absorb attacks, accelerate traffic, cache content at the edge, terminate TLS, and make “bad days” less visible.

But today’s outage showed the other side of that coin:

• When you put a large share of your customer-facing traffic behind a single intermediary,
• And when that intermediary also provides DNS, WAF, CDN, DDoS protection, API gateways, bot filtering, Turnstile/captcha, etc.,
• Then a single latent bug or internal network issue in that intermediary can amplify into a systemic outage affecting thousands of services simultaneously.

Most users didn’t say “Cloudflare is down” today.
They said “X is down”, “ChatGPT is broken”, “my bank website doesn’t work”, “my SaaS tool is down”.

From a technical perspective, many of those services were healthy at the origin. The problem was in the middle: in the connective tissue of the internet.

Digital dependency is not abstract, it is layered

When we talk about digital dependency, we are not just talking about “we use Cloudflare” or “we are on AWS”.

We are talking about chains of dependencies:

• Your application depends on a CDN or reverse-proxy provider.
• That provider depends on multiple transit operators and backbone links.
• Your DNS depends on a specific registrar and a small set of authoritative providers.
• Your authentication may depend on a third-party identity provider.
• Your customer service may depend on a single SaaS chatbot or ticketing platform.
• And all of this often sits in one or two legal jurisdictions.

Most organisations don’t have a structured view of those dependencies.
They see their own apps, maybe their cloud provider. But they don’t see the full stack of:

• Software
• Infrastructure
• Third-party services
• Jurisdictional and geopolitical exposure

Today’s incident is exactly the kind of event that exposes this blind spot.

Introducing IRN: Indice de Résilience Numérique

For the past months, I’ve been working with others on an open standard called IRN – Indice de Résilience Numérique.

You can find more information (in French for now) here: resiliencenumerique.com.

The idea behind IRN is simple but ambitious:

Provide a structured, transparent way to measure and visualise the resilience of an information system by mapping its dependencies across technical, organisational, legal, and geopolitical dimensions.

Concretely, IRN is meant to help organisations:

• Identify their critical components and the chains of dependency behind them (DNS, CDN, PaaS, SaaS, data centres, jurisdictions, suppliers…).
• Understand where they are over-dependent on a single vendor, region or technology.
• Simulate the impact of events like today’s Cloudflare outage or a region-wide cloud failure.
• Plan mitigation strategies: multi-provider DNS, multi-CDN, multi-cloud, on-prem fallback, contractual clauses, etc.

IRN is not a product; it is a shared language and methodology.
An open standard that anyone can adopt, extend, or implement.

A small, pragmatic open source step: multi-DNS & multi-CDN failover

In parallel to this conceptual work, I wanted to offer something immediately usable today.

So I published an open source project on GitHub that implements a very pragmatic piece of resilience around the exact kind of event we saw today:

A minimal multi-DNS / multi-CDN failover toolkit that keeps Cloudflare DNS and deSEC (EU and open-source based + free) DNS in sync, and lets you automatically switch traffic between Cloudflare and a secondary CDN (for example Bunny) when the primary path is unhealthy.

The core ideas:

• Use Cloudflare + deSEC as authoritative DNS providers (multi-NS).
• Model a small subset of your DNS zone in a YAML file (non-destructive; it never touches records you don’t declare).
• Introduce a web-router.example.com CNAME that points either to:
  • cf-front.example.com (Cloudflare front), or
  • cdn2-front.example.com (secondary CDN front).
• Use a small Python script to:
  • Health-check your primary path,
  • Fall back to the secondary path if needed,
  • Update the router CNAME in both Cloudflare and deSEC via API.

This is not meant to be “the solution to everything”.
But it is a concrete building block you can plug into your own infrastructure as part of a broader resilience strategy.

Resilience is a mindset, not a checkbox

If there is one lesson I hope we all take away from today, it’s this:

• Outages at hyperscalers and critical internet providers will happen again.
• They are not fully avoidable.
• What we can change is how much damage they cause to our societies, our organisations, and our users.

That means:

• Mapping our dependencies systematically (this is what IRN aims to help with).
• Designing architectures that assume providers can fail (multi-DNS, multi-CDN, multi-cloud, graceful degradation).
• Testing our scenarios regularly (chaos engineering, game-days, red team exercises).
• Bringing resilience discussions out of the purely technical realm and into strategy, governance, and regulation.

Today’s Cloudflare outage was annoying for many.
Tomorrow, a similar event could impact healthcare, energy, public safety, financial stability if we are not careful.

If you are interested in these topics; resilience, digital dependency, IRN, or the open source tools I am publishing; feel free to reach out. This work will move faster if we build it together.