Your CDN is invisible when it works and catastrophic when it doesn't. Content delivery networks sit between your origin server and your users, accelerating static assets, absorbing traffic spikes, and providing geographic distribution — but they introduce failure modes that standard uptime monitoring doesn't catch. This guide covers why CDN monitoring matters, what to monitor, and how to use Vigilmon probes across multiple regions to detect CDN edge failures before your users report them.
Why CDN Monitoring Matters
A CDN is not a passive relay. It is an active layer in your stack with its own failure modes:
Cache purge failures: your deployment updated a JavaScript bundle, but the CDN continues serving the old version. Users see a broken app; your origin returns 200. Standard monitoring shows green while users experience a broken product.
Origin pull errors: the CDN edge node attempts to fetch a resource from your origin but gets a 5xx error or times out. The CDN may return a stale cached version, an error page, or a misleading response that differs from what your origin would serve a direct request.
Edge node outages: a specific CDN point-of-presence (PoP) in a geographic region goes down. Users in that region experience degraded performance or errors while users in other regions (and your monitoring probe in one location) see nothing wrong.
SSL certificate expiry on CDN domains: your CDN front-end domain has a separate certificate lifecycle from your origin. A certificate expiring on the CDN layer causes TLS handshake failures for all users, even if your origin's certificate is valid.
Configuration drift: a CDN rule change — a redirect, a header modification, a cache behavior adjustment — breaks a specific content type or URL pattern. The CDN itself is healthy; the misconfiguration is the problem.
None of these failures are reliably detected by a single probe checking a single endpoint from a single location. CDN monitoring requires geographic breadth and awareness of what "correct" looks like at each layer.
What to Monitor
1. CDN Endpoint Availability
The most basic check: is your CDN-fronted domain responding at all?
Monitor your production domain (the URL users actually access, routed through the CDN) with an HTTP/HTTPS check. Set expected response: 200 OK. Configure a check interval of 1–5 minutes.
This catches total CDN outages — the CDN itself returning errors or being unreachable — but won't catch subtle issues like serving stale content or misconfigured caching.
2. Origin Server Availability
Monitor your origin server directly, bypassing the CDN. Use the origin's direct IP or an internal hostname that routes to the origin without going through CDN edge nodes.
Compare origin status against CDN status:
- Both down: infrastructure failure at the origin level
- Origin down, CDN up: CDN is serving cached content — appropriate short-term, but the origin needs immediate attention
- Origin up, CDN down: CDN failure is isolating your users from a working origin
- Both up: healthy
This two-layer check is the minimum for any CDN-fronted service.
3. Geographic Performance Monitoring
CDN edge node failures are inherently geographic. A PoP outage in Frankfurt affects European users; your monitoring probe in Virginia sees nothing.
Use Vigilmon's multi-region consensus probes to check your CDN endpoint from multiple geographic locations simultaneously. Configure probes from at least:
- North America (US East, US West)
- Europe (UK, Central Europe)
- Asia-Pacific (if your user base includes this region)
Vigilmon's consensus architecture means alerts only fire when multiple regions agree there's a problem — filtering single-probe network noise. But it also means you can detect regional degradation by comparing which probes report elevated response times versus which report normal operation.
4. Response Headers for Cache Status
CDNs typically expose cache status through response headers:
X-Cache: HIT/X-Cache: MISS(CloudFront, many others)CF-Cache-Status: HIT/MISS/EXPIRED(Cloudflare)X-Served-By(Fastly)Age: <seconds>(how long the response has been cached)
While Vigilmon HTTP checks don't parse response headers for alerting conditions, you can monitor cache health by checking a specific cacheable resource and watching its response time. A sudden spike in response time on a previously cached asset often indicates cache misses — the CDN is hitting the origin on every request.
Combine Vigilmon's response time history with manual header inspection when you see latency anomalies.
5. SSL Certificate Monitoring for CDN Domains
CDN front-end certificates are managed separately from origin certificates. A certificate issued through your CDN provider — Cloudflare, CloudFront, Fastly — has its own expiry date and renewal pipeline.
Monitor TLS validity on your CDN domain specifically. Vigilmon's HTTPS checks fail on certificate errors by default, which means a certificate expiry on the CDN layer will trigger a downtime alert before your users encounter TLS handshake failures in their browsers.
For domains with multiple CDN-fronted subdomains (CDN for static assets, separate CDN config for API), add each as a separate Vigilmon monitor.
Setting Up Vigilmon for CDN Monitoring
Here's a practical Vigilmon configuration for a typical CDN setup:
Monitor 1: CDN endpoint (production domain)
- URL:
https://yourapp.com(orhttps://assets.yourapp.com) - Type: HTTP/HTTPS
- Interval: 1 minute (paid) or 5 minutes (free tier)
- Expected status: 200
- Alert channel: Slack or PagerDuty
Monitor 2: Origin server (direct)
- URL:
https://origin.yourapp.com(direct origin hostname) - Type: HTTP/HTTPS
- Interval: 1 minute
- Expected status: 200
- Alert channel: same Slack channel, lower urgency
Monitor 3: CDN API endpoint (if separate)
- URL:
https://api.yourapp.com/health - Type: HTTP/HTTPS
- Interval: 1 minute
- Expected status: 200
Monitor 4: TCP port on origin (optional)
- Host: origin IP or hostname
- Port: 443 or 80
- Type: TCP
- Interval: 5 minutes
This four-monitor setup catches:
- Complete CDN outages (Monitor 1 fails, Monitor 2 may be fine)
- Origin failures regardless of CDN caching (Monitor 2 fails)
- API-specific failures separate from static asset delivery (Monitor 3)
- Low-level connectivity to origin (Monitor 4)
All four monitors fit within Vigilmon's free tier.
Detecting CDN Edge Failures with Multi-Region Probes
Edge node failures are the hardest CDN failure mode to detect. Here's the pattern:
- A CDN PoP in a specific region goes down or degrades
- Users in that region see errors or elevated latency
- Your single-region monitoring probe in a different region sees nothing
Vigilmon's multi-region probe architecture means your HTTP check runs from multiple independent locations simultaneously. When the CDN PoP in Europe fails, the Vigilmon probes in European regions report the failure. Because consensus requires multiple probes to agree on an outage, a single-region PoP failure that only affects some probes will appear as elevated response time rather than a full outage — which is accurate: it's a regional degradation, not a complete outage.
Practical interpretation:
- All probes fail: complete CDN outage — fire high-severity alert
- Some probes fail consistently: regional CDN edge node issue — investigate geographic distribution of affected probes
- Response times elevated across some probes: CDN performance degradation in specific regions — worth investigating before it escalates
Common CDN Failure Scenarios and How to Detect Them
| Failure | Detection method | |---|---| | Complete CDN outage | CDN endpoint monitor fails | | Origin pull failure (CDN serving stale/errors) | Origin direct monitor fails while CDN monitor shows 200 | | Regional edge PoP down | Multi-region probes show failures from specific geographic probe set | | SSL cert expiry on CDN domain | CDN endpoint HTTPS check fails with TLS error | | Cache purge failure (stale assets) | Response time monitoring (cached hits are fast; bypassed origin is slower) | | CDN configuration error (wrong redirect, header) | HTTP endpoint check fails or returns unexpected status code |
Alerting Configuration
CDN failures often have cascading impact. Configure your Vigilmon alerts for immediate notification:
- Primary channel: Slack or PagerDuty with immediate escalation for CDN endpoint failures
- Secondary channel: email for origin server alerts (origin failures behind a CDN may not immediately affect users if the CDN has cached content)
- Webhook: integrate with your incident management tool for automated incident creation
Use Vigilmon's webhook support to trigger your runbook — automated cache purges, CDN provider status checks, origin health validation — when a CDN monitor fails.
Conclusion
CDN monitoring is not optional for any service that uses a content delivery network in its production stack. Cache purge failures, regional edge outages, origin pull errors, and SSL certificate issues are all real failure modes that standard single-probe monitoring won't reliably detect.
The monitoring stack for a CDN-fronted service:
- Monitor the CDN endpoint from multiple regions (Vigilmon multi-region probes)
- Monitor the origin server directly as a separate check
- Monitor SSL certificate validity on CDN domains via HTTPS checks
- Use response time history to detect cache bypass and performance degradation
- Configure immediate alerting for CDN failures — they affect all users simultaneously
Vigilmon's multi-region consensus architecture makes it particularly well-suited for CDN monitoring: the same geographic distribution that eliminates false positives from single-probe network events also gives you the regional visibility needed to detect CDN edge node failures.
Add your CDN endpoint to Vigilmon for free at vigilmon.online — no credit card required.
Tags: #monitoring #cdn #devops #webperformance #infrastructure