What Is CDN Failover? How It Works, and Why Single-CDN Setups Break

CDN failover is the automatic process of redirecting traffic away from a failed or degraded CDN provider to a healthy backup, so that a website or application stays online without manual intervention. When a CDN's edge servers stop responding — due to an outage, a routing issue, or a misconfiguration — failover mechanisms detect the failure and reroute requests before users notice anything went wrong.

It sounds simple. In practice, it's one of the most misunderstood parts of modern web infrastructure — and one of the most expensive to get wrong.

Why CDN Failover Matters Now

Content Delivery Networks were built to solve a performance problem: serve content from edge locations close to users instead of a single origin server far away. That part works well. What CDNs don't inherently solve is what happens when the CDN itself goes down.

Every major CDN — Cloudflare, Akamai, Fastly, AWS CloudFront — has experienced outages that took down large parts of the internet, sometimes for hours. If your infrastructure depends on a single CDN provider with no failover path, a provider-side incident becomes your incident. Your team can't fix someone else's outage; the only real protection is not depending on just one.

How CDN Failover Works

Most failover systems follow the same three-stage pattern, regardless of the specific tooling:

1. Detection. Health checks — synthetic monitoring probes running from multiple locations — continuously test whether a CDN's edge nodes are responding correctly. Detection needs to be fast and resistant to false positives: a single failed probe shouldn't trigger a full failover, but a sustained pattern of failures across regions should.

2. Traffic redirection. Once a failure is confirmed, traffic is rerouted using one of a few mechanisms:

• DNS-based failover — DNS records are updated to point away from the failed provider toward a healthy one. This is the most common approach, but it's constrained by DNS TTL (time-to-live): if your TTL is set to an hour, that's roughly how long it can take clients to pick up the change, unless you're using a provider built to override that.
• Load-balancer failover — a load balancer sitting in front of multiple CDNs actively routes each request to a healthy backend, without waiting on DNS propagation at all.
• Anycast failover — traffic is routed at the network layer to the nearest available node, which can shift automatically when a node or region goes dark.

3. Recovery. Once the primary CDN is confirmed healthy again, traffic is gradually shifted back — usually incrementally, not all at once, to avoid overwhelming a provider that's still stabilizing after an incident.

CDN Failover vs. CDN Failure

These two terms get mixed up constantly, so it's worth separating them clearly:

• CDN failure is the event — the CDN provider itself experiencing downtime, degraded performance, or unreachable edge nodes.
• CDN failover is the response — the mechanism that detects the failure and moves traffic elsewhere.

A CDN can fail without failover ever kicking in, if there's no failover system in place at all. That's the situation most single-CDN setups are quietly in.

Is CDN Failover Before or After the Load Balancer?

This depends on the architecture, and both patterns exist:

• Load balancer in front of CDNs: a load balancer (or a multi-CDN control plane) sits above multiple CDN providers and decides, per request, which one to send traffic to. Failover happens at the load balancer layer — it simply stops sending traffic to the unhealthy provider.
• CDN in front of load balancers: in simpler setups, a single CDN sits in front of your own load-balanced origin servers. Here, failover only protects your origin infrastructure — it does nothing if the CDN itself is the thing that fails, since there's no layer above it to fail over to.

If your goal is resilience against a CDN-provider outage specifically — not just origin server failure — you need the first pattern: something orchestrating traffic across multiple CDNs, not just behind one.

What Is CDN Stacking?

CDN stacking refers to running multiple CDN providers simultaneously rather than switching between them only during an outage. There are two common approaches:

• Active-passive stacking: one CDN handles all traffic under normal conditions; a secondary CDN activates only during failover. Simpler to operate and typically cheaper, since the secondary provider only needs to handle load occasionally.
• Active-active stacking: traffic is distributed across multiple CDNs continuously, based on real-time performance, cost, or geographic routing. More resilient and often faster, but operationally more complex — and typically more expensive, since you're paying multiple providers for live traffic.

Building CDN Failover: What Actually Matters

If you're evaluating or building CDN failover for production traffic, a few things determine whether it works when you actually need it:

• Detection speed vs. false positives. Failover that triggers too eagerly causes unnecessary flapping between providers. Failover that's too conservative means longer real outages before it kicks in.
• DNS TTL is a hard constraint for DNS-based failover — low TTLs mean faster failover, but also more DNS query volume and cost.
• Test it before you need it. Failover systems that have never been tested under real conditions are unreliable by default. Regular failover drills — deliberately simulating a provider outage — are the only way to know your system actually works.
• Recovery matters as much as failover. A system that fails over correctly but floods a recovering provider with 100% of traffic instantly can cause a second outage. Gradual traffic restoration avoids this.

Classify Traffic Before You Design Failover

Not all traffic deserves the same failover treatment. Before choosing an architecture, it helps to classify what your application actually serves and what must keep working during a partial outage:

• List major request types — HTML, APIs, images, video, downloads, third-party scripts — separately, since their risk profiles differ.
• Assign business criticality to each: checkout and authentication are rarely optional, while a recommendation widget usually can degrade without real damage.
• Define what degradation is acceptable per category — slower images are typically fine; a broken login generally isn't.

This classification step prevents both over-engineering (paying for instant active-active failover on traffic that didn't need it) and under-engineering (discovering during a real incident that your most critical traffic had the weakest protection).

Why a Second CDN Alone Doesn't Solve the Problem

Buying a second CDN provider is the easy part. Multi-CDN setups fail in avoidable, repeatable ways: mismatched TLS certificates, inconsistent cache headers, missing origin allowlists, or stale WAF rules on the secondary provider. A site that works perfectly on the primary CDN can break subtly on the backup, because header normalization, cache defaults, and edge behavior differ between vendors even when both look correctly configured on paper.

The more common failure mode is operational drift: the backup path gets configured once, then quietly falls out of sync as the application changes over time. By the time a real incident happens, the secondary CDN no longer reflects current site behavior — a gap that stays invisible until traffic actually needs to use it.

The Bottom Line

CDN failover isn't a feature you get automatically by using a CDN — it's an architectural decision that requires monitoring, a redirection mechanism, and a second (or third) provider to fail over to, kept genuinely production-ready rather than configured once and forgotten. Single-CDN infrastructure has no answer to a CDN-provider-side outage, no matter how good that provider's uptime record is.

Read the complete guide to multi-CDN traffic steering and failover →