A CDN can keep a website fast while quietly serving stale files, bypassing the cache, or sending every request back to the origin. A scheduled web cron check gives you an independent view of cache behavior and catches configuration drift before it becomes a performance or release problem.
Define healthy cache behavior
Start with representative URLs and an explicit expectation for each one. A versioned CSS file should normally be cached for a long time, a product page may have a short edge lifetime, and an account page should often bypass shared caching. Monitoring is useful only when pass and fail rules match the content.
Inspect the headers that explain the response
Record status, final URL, Cache-Control, Age, ETag or Last-Modified, Vary, and the CDN-specific cache-status header. Provider labels differ, so normalize them into hit, miss, bypass, expired, revalidated, or unknown. Never assume that HTTP 200 means the cache is healthy.
Use a two-request probe
For cacheable assets, request the same URL twice with a short gap. The first response may be a legitimate miss; the second should usually become a hit and show an increasing age. Use a unique diagnostic query only when your CDN policy explicitly includes or ignores it. Otherwise the probe can create noise or bypass the cache it is supposed to test.
Test several content classes
- Versioned static assets with long lifetimes.
- HTML pages with short or revalidated caching.
- API responses that are intentionally public-cacheable.
- Private routes that must never enter shared cache.
- Redirects and error pages with documented policies.
Pair these probes with scheduled API health checks so availability and cache behavior remain separate signals.
Compare edge and origin evidence
A protected diagnostic endpoint can expose the current release identifier or content checksum. Compare it with the public response without returning secrets. If the edge serves an older release beyond the approved propagation window, flag staleness. Secure the checker using the guidance for web cron endpoints.
Choose practical thresholds
Measure a baseline before alerting. Useful conditions include repeated misses for a normally hot asset, an age that never advances, a stale release after deployment, unexpected caching of private content, or origin latency rising while hit ratio falls. Require consecutive failures for transient regional events.
Probe regions responsibly
If your monitoring platform offers multiple locations, run the same small test from a few important regions. Do not request large files or purge content during routine checks. Group regional failures into one incident and identify whether the problem is local to an edge location or global.
Alert with enough context
Include URL class, region, normalized cache state, Age, cache directives, release identifier, response time, and last known good check. Link to a runbook covering CDN rules, origin headers, purge history, deployments, and vendor status. Send a recovery message after stable success.
Test changes safely
In staging, simulate an incorrect no-store rule, a stale asset, a missing Vary header, and a private page marked public. Verify detection and recovery. After deployments, watch the propagation window and use scheduled cache refresh only when invalidation is intentional.
Common mistakes
- Checking only response status.
- Expecting every first request to be a hit.
- Using cache-busting parameters during the probe.
- Ignoring private-content caching risks.
- Comparing provider-specific labels without normalization.
- Downloading large assets too frequently.
Rollout checklist
- Inventory URL classes and expected policies.
- Normalize cache headers and states.
- Implement a bounded two-request probe.
- Add protected release or checksum evidence.
- Set baseline-driven thresholds.
- Test critical regions and group alerts.
- Simulate misses, staleness, bypass, and recovery.
CDN monitoring works best when it checks the behavior users depend on: correct freshness, predictable caching, and protection for private responses. A focused web cron job can verify those properties continuously without adding meaningful load.