CDN Monitoring
Know whether your CDN is caching — and what it actually saves.
A CDN is supposed to answer from a nearby edge without bothering your origin. When a header change, a cookie or a new deploy quietly turns every request into a cache miss, the site still works — it is just slower and your origin is busier, and nothing alerts. NetTests records which CDN answered, from which edge, and whether it came from cache, on every scheduled check.
Why a CDN fails silently
An uptime check sees a 200 and moves on. It cannot tell a response served from a CDN cache
in 20 ms from one that travelled to your origin and back in 400 ms — both are "up". So the
common CDN failures never page anyone: a Set-Cookie or Vary header
that makes every response uncacheable, a cache rule lost in a configuration change, a
deploy that purges everything and keeps purging, a path routed around the CDN entirely.
The cost shows up elsewhere: higher origin load and bills, slower first bytes for every visitor, and Core Web Vitals that drift without any code change to explain them.
How NetTests monitors your CDN
Every scheduled HTTP check reads the response headers each CDN sends and records the provider — Cloudflare, Amazon CloudFront, Fastly, Akamai, Vercel, Netlify, Bunny CDN, Azure Front Door or Google's edge — the edge location that answered, the cache result (hit, miss, revalidated, bypass or dynamic) and the cached object's age.
The cache result is stored as a metric, so a report graphs your cache-hit rate over time and a threshold can open an incident when caching stops. When a CDN has two layers — an edge and a shield — a hit at either counts: the question is whether your origin had to answer.
The CDN Check goes one step further: it requests the same path through the CDN and straight from your origin, and reports how much sooner the first byte arrived through the CDN. A CDN that is slower than the origin it fronts is worth knowing about.
Checks run from our monitoring location, so they describe the edge that location reaches. Each edge keeps its own cache — a path cached in one region can still miss in another.
Key features
Provider and edge detection
Which CDN answered and from which edge location, read from the headers each provider actually sends.
Cache-hit rate over time
Hit or miss recorded on every run and graphed as a rate, with a 30-day baseline.
CDN vs origin
Time to first byte through the CDN against the origin, and the difference in milliseconds and percent.
Phase-by-phase timing
DNS, TCP, TLS and server wait for the edge and the origin — the edge's server wait is its cache lookup.
Alerts when caching stops
A threshold on the cache-hit metric or on the CDN's saving opens an incident and notifies your team.
Origin recognition
Amazon S3, Google Cloud Storage and GitHub Pages origins are named when their headers come through.
See your CDN right now
Run the free CDN Check against any URL — no account required. Add your origin URL to see what the CDN saves, then schedule it to follow the hit rate over time.
Try CDN Check →Free CDN and HTTP tools
Inspect a CDN by hand — then automate the checks with monitoring.
Which CDN serves a URL, from which edge, whether it was cached, and what it saves over the origin.
Any request with DNS, TCP, TLS and server time, plus the CDN edge and cache result.
Every response header, including the cache and CDN headers behind a hit or a miss.
Detect the CDN, hosting and frameworks a site uses.
Frequently asked questions
What is a CDN cache-hit rate?
The share of requests a CDN answers from its own cache instead of fetching from your origin. A high hit rate means faster first bytes for visitors and less load on your origin. NetTests measures it from the outside: each scheduled check is one sample, so the rate over a week is the share of those checks that were hits.
Which CDNs can NetTests recognise?
Cloudflare, Amazon CloudFront, Fastly, Akamai, Vercel, Netlify, Bunny CDN, Azure Front Door and Google's edge — from the headers each one sends. A CDN that sends no recognisable header is reported as not detected rather than guessed.
Why does my CDN show a miss when I expect a hit?
The usual causes are a response the CDN is told not to cache (Cache-Control: private, no-store, a Set-Cookie header), a Vary header that splits the cache too finely, a short TTL, or a recent purge. Each edge also keeps its own cache, so the first request to a quiet edge is a miss.
Can it compare the CDN with my origin?
Yes. Give the CDN Check your origin URL — a load balancer hostname, an origin subdomain or a storage bucket URL for the same path — and it reports time to first byte through the CDN, at the origin, and the difference.
Does it test from several regions?
No — checks run from one monitoring location, and results describe the edge that location reaches. For what visitors in every country experience, pair it with Real User Monitoring, which records the CDN cache result from real page views where the CDN reports it.
Find out whether your CDN is earning its place
NetTests records the CDN, edge and cache result on every check, graphs your hit rate, and opens an incident when caching stops.
Start monitoring free →