HTTP caching can make a site fast and resilient, but a single header change can quietly disable browser caching, hold stale content too long, or make a CDN reuse a response for the wrong request. A scheduled external check can capture the complete cache contract, compare it with an approved baseline, and alert when a deployment changes freshness, validation, privacy, or edge behavior.
Monitor behavior, not just header presence
A cache check should request a controlled public resource through the same hostname and CDN route used by visitors. It must inspect response headers, save validators, repeat the request, and verify whether the second response behaves as expected. Looking only for a Cache-Control header misses conflicts, ignored directives, incorrect cache keys, and broken revalidation.
Choose several representative URLs rather than scanning the whole site: a fingerprinted static asset, an HTML page, a public API response, and a private or personalized route that must never enter a shared cache.
Define an approved cache contract
Write the expected behavior for each probe before creating alerts. A versioned JavaScript bundle may allow a long public lifetime with immutability. HTML may need a short lifetime and revalidation. A user dashboard may require private or no-store. Store the contract as structured data so the monitor can explain which expectation changed.
- expected Cache-Control directives and allowed ranges;
- whether Expires is used and whether it agrees with Cache-Control;
- required ETag or Last-Modified validators;
- allowed Vary fields and cache-key dimensions;
- expected edge cache status and Age behavior;
- whether stale-while-revalidate or stale-if-error is permitted;
- privacy rules for cookies, authorization, and personalized responses.
Parse Cache-Control correctly
Do not compare the header as an exact string. Directive order is not significant, values may use quoted syntax, and intermediaries can add extensions. Parse directives into normalized keys and values, then apply policy. Detect contradictions such as public with private, a negative max-age, or an unexpectedly missing no-store.
When s-maxage is present, evaluate it separately from browser max-age. A CDN can keep a response longer than a browser, which may be intentional, but it must match the documented shared-cache policy.
Test fresh cache hits
Send a normal GET request with a unique monitoring marker that does not alter the cache key. Record the first response, wait briefly, then repeat through the same route. Verify that the resource body or digest is stable, Age increases when exposed, and the CDN status changes from miss to hit when the platform provides a safe cache-status header.
Do not treat vendor-specific headers as the only truth. A response can say hit while returning the wrong object. Validate content type, content length range, digest, and expected version marker as well.
Exercise conditional revalidation
Save the ETag and Last-Modified values from the first response. Send If-None-Match or If-Modified-Since on a later request and verify the expected 304 response or a valid changed representation. Confirm that validators remain stable for unchanged content.
A weak validator can be appropriate for semantically equivalent content, while a strong validator should change when bytes change. Alert when a validator disappears from a resource whose short freshness depends on efficient revalidation.
Check cache-key isolation
The Vary header tells shared caches which request headers produce different representations. Test approved variants such as content encoding, language, or device class by sending a small matrix of requests. Confirm that each variant returns the expected representation and that the cache does not leak one variant into another.
Keep the matrix intentionally small. Do not iterate through arbitrary headers. Focus on dimensions the application claims to support and record the resulting cache-status evidence.
Protect private responses
For routes that use cookies or authorization, verify that responses are marked private or no-store according to policy and that shared-cache indicators never show a reusable hit. Use a synthetic monitoring account with no sensitive data. Never place credentials in URLs, screenshots, logs, or alert messages.
If a dedicated endpoint performs these checks, secure it with the practices in Secure Web Cron Endpoints. Return concise classifications instead of raw authorization headers or complete response bodies.
Detect compression and encoding mistakes
A cache must separate compressed and uncompressed representations when both are served. Request an approved encoding and verify Content-Encoding, Vary, and body decoding. A missing Vary: Accept-Encoding can cause incompatible bytes to reach clients through an intermediary.
Also confirm that range responses, downloads, and streaming endpoints follow their documented cache policy. These paths often differ from ordinary HTML and static assets.
Compare origin and edge behavior
When safe and supported, run one probe through the public CDN and another against a controlled origin-health hostname. Differences reveal where headers are rewritten. Do not bypass access controls or expose a private origin merely for monitoring.
Record the edge region, protocol version, final URL, and any approved surrogate cache headers. A regression limited to one region may indicate a partial configuration rollout rather than an application deployment.
Watch freshness over time
A header snapshot cannot prove that a cache expires when it should. Schedule an extended probe that observes Age or equivalent evidence across the expected lifetime, then confirms revalidation or a fresh fetch after expiry. Run this less often than the short regression check.
Use synchronized clocks when comparing Date, Expires, Age, and local timestamps. The safeguards in Server Clock Drift Monitoring prevent false alerts caused by inaccurate probe time.
Choose safe baselines
Do not blindly learn whatever headers are present during the first run. Review and approve the intended contract, then version it alongside deployment changes. Allow narrow ranges for values such as max-age, but require exact policy for privacy directives and Vary dimensions.
When an intentional change is released, update the baseline in the same change window. The monitor should still record the old and new normalized contracts so reviewers can confirm the transition.
Schedule and retry deliberately
Run a lightweight contract check every five to fifteen minutes for important sites. Use strict connection and response timeouts. One bounded retry can handle transient network loss, but it must preserve the first response and region.
Apply the evidence-first retry approach in Cron Job Retry Strategies. A retry that succeeds should classify the event as intermittent, not erase it.
Design actionable alerts
Alert on material changes: a long-lived asset becomes uncacheable, private content becomes public, validators vanish, Vary loses a required dimension, revalidation stops working, or an edge serves an unexpected body. Include the URL class, region, normalized before-and-after directives, validator result, cache-status evidence, and deployment correlation.
A general HTTP 500 or timeout belongs in availability monitoring. The cache alert should focus on the contract so the receiving team knows whether to inspect application headers, CDN rules, or deployment configuration. The bounded validation pattern in Scheduled API Health Checks keeps these classifications clear.
Operational checklist
- Probe representative static, HTML, API, and private routes.
- Normalize directives instead of comparing raw header strings.
- Verify cache hits, Age, validators, and conditional requests.
- Test only approved Vary and encoding dimensions.
- Confirm shared caches never reuse private responses.
- Compare regions and origin behavior where safe.
- Version the approved contract and retain before-and-after evidence.
Cache performance depends on policy remaining correct after every deployment. A scheduled monitor turns invisible header drift into a reviewable signal, catching disabled caching, stale content, broken revalidation, and privacy risks before they spread across browsers and edge nodes.