CDN and Uptime: How Content Delivery Networks Improve Availability

Your web server sits in one location. Your visitors come from everywhere. The further a visitor is from your server, the longer it takes for your pages to load. And if that one server goes down, your entire site goes with it.

A content delivery network (CDN) addresses both of these problems by distributing copies of your content across servers worldwide. CDNs are primarily known as a performance tool, but they also have a significant impact on uptime and availability. Understanding how CDNs interact with your uptime strategy helps you make better infrastructure decisions.

How a CDN Works

A CDN is a network of servers, called edge servers or points of presence (PoPs), distributed across multiple geographic locations. When you put your website behind a CDN, the CDN caches copies of your static content (images, CSS, JavaScript, HTML pages) on these edge servers.

When a visitor in Tokyo requests your page, they connect to a CDN edge server in Tokyo instead of your origin server in Virginia. The edge server serves the cached content directly, without making a round trip to the origin. This is faster for the user and reduces load on your origin server.

The process works like this:

1. A visitor's browser sends a request for your page.
2. DNS directs the request to the nearest CDN edge server.
3. If the edge server has a cached copy (cache hit), it serves it immediately.
4. If the edge server does not have a copy (cache miss), it fetches the content from your origin server, serves it to the visitor, and caches it for future requests.

Popular CDN providers include Cloudflare, Amazon CloudFront, Fastly, Akamai, and Bunny. Each operates a global network of edge servers, though the number and distribution of locations varies.

How CDNs Improve Uptime

CDNs improve your website's availability in several concrete ways. Here is how each mechanism works.

Absorbing Traffic Spikes

Your origin server has a finite capacity. If a viral social media post sends 50 times your normal traffic, the origin server can become overwhelmed and stop responding. Your site goes down under the load.

A CDN absorbs most of this traffic at the edge. If 90% of requests are for cached content, only 10% reach your origin. A 50x traffic spike becomes a 5x spike on your origin, which is far more survivable. The CDN's edge servers are designed to handle massive traffic volumes, and the load is distributed across dozens or hundreds of servers worldwide.

This is one of the most practical uptime benefits of a CDN. Traffic spikes that would crash a single server barely register on a CDN. For more on preparing for traffic surges, see website load testing.

Origin Shielding

When multiple edge servers need to fetch the same piece of content from your origin, they can overwhelm the origin with simultaneous requests. Origin shielding adds an intermediate cache layer between the edge servers and your origin. Instead of 50 edge servers each requesting the same file, the shield server makes one request to the origin and distributes the response to all the edge servers.

This dramatically reduces the load on your origin during cache misses and protects it from the thundering herd problem, where a cache expiration causes a stampede of requests to the origin.

Serving Stale Content During Origin Outages

Many CDNs can continue serving cached content even when your origin server is completely down. This feature, often called "stale-while-revalidate" or "always online," serves the last known good version of your pages when the origin is unreachable.

Your site will not be fully functional. Dynamic features like login, search, and form submissions will not work. But visitors will see your pages instead of an error screen. For informational sites, blogs, and marketing pages, this means the site remains usable even during an origin outage.

Not all CDN configurations enable this by default. Check your CDN settings to confirm that stale content serving is turned on.

DDoS Mitigation

Distributed denial-of-service attacks attempt to overwhelm your server with fake traffic. CDNs act as a shield because the attack traffic hits the CDN's edge network, not your origin server. CDNs have the capacity to absorb attack traffic that would instantly take down a single server.

Most major CDN providers include DDoS protection as a built-in feature. Some offer additional layers like Web Application Firewalls (WAFs) that filter malicious traffic before it reaches your origin.

DNS-Level Redundancy

CDNs typically use anycast DNS, which routes requests to the nearest healthy edge server. If an edge server goes down, DNS automatically routes traffic to the next nearest server. This failover happens without any intervention from you.

This contrasts with a traditional single-server setup where a server failure means the site is down until someone fixes it or manually switches to a backup.

The CDN Is Not a Substitute for Monitoring

CDNs improve uptime, but they do not eliminate the need for uptime monitoring. Here is why.

CDN Failures Happen

CDNs are not immune to outages. Major CDN outages have taken down large portions of the internet:

• In June 2021, Fastly experienced a global outage that affected Amazon, Reddit, Twitch, and hundreds of other sites for about an hour.
• Cloudflare has had incidents affecting specific regions or services.
• AWS CloudFront has experienced degraded performance during broader AWS incidents.

If your CDN goes down, your site goes down (or severely degrades) even if your origin server is perfectly healthy. Monitoring your site through the CDN, as a real user would access it, catches these failures. For broader context on how to handle outages of services you depend on, see the website downtime guide.

Origin Health Still Matters

For dynamic content, user authentication, API calls, and anything that cannot be cached, your origin server is still in the critical path. The CDN handles static assets, but the origin handles the application logic. If the origin is down, cached pages might load but the site will not function properly.

Monitor both your CDN-served URLs and your origin server directly. This tells you whether a problem is at the CDN layer or the origin layer, which matters for knowing where to focus your troubleshooting.

Cache Misses Expose the Origin

The first request for any uncached content goes to the origin. After a deployment, cache purge, or cache expiration, many requests hit the origin simultaneously. If the origin is struggling, these cache misses expose the problem to users.

Choosing a CDN for Uptime

When evaluating CDNs with uptime in mind, look at these factors:

Network size and distribution. More edge locations means better coverage and faster failover. Check whether the CDN has PoPs in the regions where your users are concentrated.

Stale content policies. Confirm the CDN can serve cached content when the origin is down. Check how long it will serve stale content and whether you can control this behavior.

DDoS protection. Evaluate the CDN's DDoS mitigation capacity and whether it is included in your plan or costs extra.

Origin shielding. This feature reduces origin load and is especially valuable if your origin has limited capacity.

Uptime history. Review the CDN provider's own status page and incident history. A CDN with frequent outages adds risk rather than reducing it.

Monitoring integration. Some CDNs provide their own analytics and alerting. These complement but do not replace independent uptime monitoring from outside the CDN's network.

Monitoring a CDN-Fronted Site

When your site is behind a CDN, your monitoring setup needs a few adjustments.

Monitor the public URL. Your users access your site through the CDN, so your uptime checks should too. This catches CDN-layer problems.

Monitor the origin directly. Set up a separate check that hits your origin server's IP or a non-CDN hostname. This catches origin problems that the CDN might be masking with cached content.

Test from multiple locations. CDN performance and availability can vary by region. Multi-location monitoring ensures you catch regional CDN issues, not just problems visible from one monitoring location.

Check response content, not just status codes. A CDN might return a 200 status code with a stale or error page from its own cache. Content checks verify that the response contains expected text, catching cases where the CDN serves something unexpected.

Key Takeaways

• A CDN distributes your content across edge servers worldwide, reducing load on your origin and improving availability.
• CDNs improve uptime by absorbing traffic spikes, serving stale content during origin outages, mitigating DDoS attacks, and providing DNS-level failover.
• CDNs are not immune to outages. Monitor your site through the CDN to catch CDN-layer failures.
• Monitor both your public URL (through the CDN) and your origin server directly.
• A CDN is a layer of resilience, not a replacement for a reliable origin and proper uptime monitoring.