CDN Monitoring: Catch Edge, Cache, and Origin Failures

Your site is fast. Your origin server is healthy. Your status page is green.

Then a CDN edge in Frankfurt starts returning 503s for an hour. Customers in Germany get errors while every other region works fine. You don't notice because your monitoring runs from one US region. The CDN provider's status page lists nothing — the failure is too localized to be classified as an incident.

CDNs are critical infrastructure for nearly every modern site, and yet most teams have minimal visibility into how their CDN is actually performing. The dashboards you get from Cloudflare, Fastly, CloudFront, Akamai, and Bunny each show their own slice of reality, often filtered through the provider's own incentive to look healthy. The only reliable way to know your CDN is working for your users is to monitor it yourself.

This guide covers what to monitor across any CDN, what each major provider does and doesn't expose, and how to catch the failure modes that don't show up on a status page.

Why CDN Monitoring Is Different

A CDN sits between your users and your origin. That gives it a unique failure profile:

Per-region failures — A CDN can be healthy globally and broken in a single PoP (point of presence) for hours
Cache vs. origin behavior — A cached response can be fast and stale; an origin response can be slow but fresh
Asymmetric outages — Some users see issues, others don't, depending on which edge they hit
Provider status pages lie by omission — Localized issues often aren't acknowledged unless they affect many customers

A standard uptime check from a single location won't catch any of these. CDN monitoring is fundamentally about coverage across regions and behaviors.

What to Monitor

1) Edge Availability by Region

Run HTTP checks from multiple geographic regions and compare results. If Tokyo returns 200 in 80ms and São Paulo returns 503 from the same URL, you have a CDN-level issue at one PoP — even if the provider doesn't know yet.

At minimum monitor from North America, Europe, and one of Asia/South America/Oceania
Match your customer geography — If you sell in 8 countries, monitor from at least one location in each
Compare regions — Alert when one region's error rate exceeds a baseline derived from the others

See Multi-Region Monitoring: Why Location Matters.

2) Cache Hit vs. Cache Miss

A CDN's job is to serve cached responses fast. If you're seeing a sudden drop in cache hit rate, your origin gets pounded and TTFB rises:

Inspect the cache status header — Cf-Cache-Status (Cloudflare), X-Cache (CloudFront), X-Served-By and X-Cache (Fastly), X-Akamai-Cache (Akamai)
Alert on misses — If a check that should hit cache returns MISS, something invalidated the cache
Track hit rate trends — A 5% drop overnight usually means a config change or a rogue query parameter

3) Origin Health Behind the CDN

Your CDN can fully mask origin issues — until cache TTLs expire. Monitor your origin directly, not just through the CDN:

Bypass-cache check with a query parameter or directly against your origin's IP/hostname
Compare response time — A widening gap between cached and origin response usually signals origin trouble
Watch 5xx rates at the origin even when the public site looks fine

Cloudflare Monitoring: Detect Origin Outages covers this pattern in depth for one provider; the principle applies to all.

4) TLS / SSL at the Edge

Most CDNs handle TLS termination, but the certificates can still fail in interesting ways:

Certificate expiry — Even auto-renewed certs occasionally fail to renew (DNS validation issues, rate limits)
Certificate chain — Some CDN configs serve incomplete chains that work in browsers but fail in older clients
TLS version negotiation — Catch when a config update accidentally drops TLS 1.2 support
SNI behavior — Multi-domain CDN configs can route to the wrong cert if SNI is misconfigured

5) DNS at the Edge

Many CDNs include managed DNS (Cloudflare DNS, Route 53 with CloudFront, Fastly DNS). If DNS breaks, your CDN doesn't matter:

Resolution from multiple resolvers — Test from 8.8.8.8, 1.1.1.1, and a regional ISP resolver
TTL tracking — Surprisingly low TTLs can amplify outages; high TTLs can prolong them
Anycast routing — Verify you're getting routed to a nearby PoP via DNS

6) Origin Shielding and Tiered Caching

If you use a shielding setup (Fastly origin shield, CloudFront tiered caching, Cloudflare Tiered Cache):

Monitor the shield region independently — Shield outages can affect your entire fleet of edges
Verify shielding is actually engaging — Check headers for evidence of shield-tier hits

7) WAF and Bot Management

CDNs run a lot of security logic at the edge. False positives kill conversions:

Synthetic checks against your "known good" paths — Confirm WAF isn't blocking legitimate requests
Bot challenge response codes — A 403 with a captcha challenge looks the same as a real outage to most monitoring tools
Per-rule firing rate — Alert when a single WAF rule starts blocking a higher-than-normal share of traffic

Common CDN Failure Modes

Failure	User Impact	How to Detect
Single PoP returns 5xx	Users in that region see errors	Multi-region HTTP checks
Cache hit rate collapse	TTFB spikes everywhere, origin overloaded	Cache header inspection + TTFB alerts
Cert renewal failed	Browser security warnings in some regions	SSL monitoring (multi-region)
Misconfigured cache key	Cache fragmentation, hit rate drops	Cache status header monitoring
Origin shield outage	Entire CDN behaves like cache miss everywhere	Shield-tier header checks
WAF false positives	Real users blocked, legitimate traffic drops	Synthetic checks on known good paths
DNS misconfiguration	Some users can't reach the site at all	Multi-resolver DNS checks
Provider-wide incident	Everyone sees errors	Provider status page + your synthetics
Stale content after invalidation	Users see old prices, old assets	Cache-busted checks vs. cached checks
Bot challenge interfering with monitoring	False positives in monitoring itself	Allowlist monitoring source IPs at WAF

Monitoring Across Major CDNs

Cloudflare

Useful headers: Cf-Cache-Status, Cf-Ray, Server-Timing
Key metrics: cache hit ratio, threats blocked, origin response time
Common pitfalls: WAF rules blocking monitoring; aggressive Bot Fight Mode causing 403s; Workers throwing exceptions silently

Amazon CloudFront

Useful headers: X-Cache (Hit from cloudfront, Miss from cloudfront, RefreshHit, Error)
Key metrics: 5xxErrorRate per origin, TotalErrorRate, ByteHitRate
Common pitfalls: behavior config drift between deployed and declared (Terraform/CFN); origin failover not engaging when expected; signed URL/cookie expiry causing widespread 403s

Fastly

Useful headers: X-Served-By (lists every PoP traversed), X-Cache, X-Cache-Hits
Key metrics: cache hit rate, origin response time, VCL errors
Common pitfalls: VCL deploys with subtle bugs; surrogate key purges that purge too much; origin shield region outages

Akamai

Useful headers: X-Akamai-Cache, X-Akamai-Edge-IP
Key metrics: edge hit ratio, midgress hit ratio, origin response time
Common pitfalls: property activation lag; long-tail PoP issues that don't trigger their own monitoring

Bunny.net

Useful headers: Cdn-Cache, Cdn-EdgeStorageId, Server
Key metrics: cache status, edge response time
Common pitfalls: pull zone misconfiguration; edge rule order bugs

Setting Up CDN Monitoring

Quick start (10 minutes)

Multi-region HTTP checks on your homepage from at least 3 regions
Cache header validation — Confirm cache status header is present and reports HIT
SSL monitoring on your apex and top subdomains
DNS monitoring with multiple resolvers
Origin direct check — Bypass cache to confirm origin is healthy independently

Comprehensive setup (45 minutes)

Add to the quick start:

Per-region 5xx rate alerts — Compare each region's error rate against the global baseline
Cache hit ratio tracking — Pull from CDN logs or API; alert on >5% drop hour-over-hour
Origin shield health — Direct checks against the shield region if you have one
WAF rule firing rate — Alert when any single rule starts blocking too much
Synthetic checks against critical paths — Login, checkout, search, API endpoints
TTFB tracking per region (see TTFB Monitoring: Diagnose Slow Server Response Times)

What to Do When CDN Monitoring Fires

Single region returning errors:

Check provider status page for that region
Run a traceroute from the affected region to your origin
Try a synthetic from a different ISP in the same region — sometimes it's an upstream issue, not the CDN
Open a ticket with the provider with HAR file and X-Served-By / Cf-Ray headers

Cache hit rate collapsed:

Check for recent config changes (cache key, cache TTL, query parameter handling)
Look for unexpected Cache-Control: no-cache or Vary headers from origin
Inspect a sample of recent requests for query string differences (analytics IDs, A/B test cookies)
Check whether a recent purge was too broad

Origin overwhelmed:

Confirm via origin metrics, not just CDN
Check cache hit ratio trend
Scale origin temporarily while you find the root cause
Look for missing cache directives on a hot endpoint

SSL or DNS alert:

Confirm with an external SSL checker from multiple regions
Check provider's certificate management dashboard
Verify DNS records in your authoritative DNS
If using DNS validation for cert renewal, verify the validation records still exist

How Webalert Helps

Webalert is built for monitoring sites behind CDNs:

Multi-region HTTP checks — see CDN behavior the way real users experience it
Content validation — verify cached pages render correct content, not just return 200
SSL monitoring — catch certificate issues at the edge before browsers block users
DNS monitoring — detect resolution problems even when the CDN itself is healthy
Response time tracking — catch CDN slowdowns and cache misses early
Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
Status pages — communicate incidents to customers and build trust during CDN events
5-minute setup — paste your URL and start monitoring globally

See features and pricing for details.

Summary

A CDN can be healthy globally and broken in a single PoP for hours; multi-region monitoring is non-negotiable.
Monitor cache status headers, not just response codes — a fast 200 from cache and a slow 200 from origin tell very different stories.
Always monitor your origin directly, not just through the CDN, so you can isolate the layer when something breaks.
Each major CDN exposes different headers and metrics; learn yours and feed them into alerts.
Watch SSL, DNS, WAF, and origin shielding as separate signals — each can break independently.
Provider status pages are necessary but not sufficient. Your synthetic checks are the source of truth.

CDNs make the internet fast. Monitoring makes sure they're actually doing it.

Catch CDN failures before your customers do

Start monitoring with Webalert →

See features and pricing. No credit card required.