HTTP Headers Inspector

When to reach for this tool

Reach for this when you need to review the headers a web service returns during setup, debugging, or an incident review. A one-off check is useful for diagnosis, but production systems need continuous monitoring once the immediate question is answered.

• Cache headers explain why you may be seeing a stale response.
• Redirect headers expose chains a status code alone hides.
• Security headers are easy to drop in a deploy and worth watching.

Response headers worth checking

A status code tells you the outcome; headers tell you why the response looks the way it does. A handful are worth reading whenever you debug a service or decide what a monitor should assert on.

• Cache-Control / Age — whether you are seeing a fresh response or a cached copy.
• Location — the target of a 3xx redirect, and the start of any redirect chain.
• Content-Type — that the response is the format you expect (HTML, JSON) rather than an error page.
• Strict-Transport-Security (HSTS) — that HTTPS is being enforced.
• Content-Security-Policy — that security policy survived the last deploy.

From one-off check to continuous monitor

Use header inspection to debug redirects, caching behavior, and security headers, then choose the exact URL and expectations your monitor should assert on.

• Recreate the same check in Sandglass on an interval so the next change is caught without re-running the lookup.
• Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever fixes the problem.
• Track the result over time instead of treating one manual reading as the final answer.

Why a lookup is not monitoring

Headers reveal what a status code hides. A page can return 200 while a cache header serves a stale copy or a redirect chain quietly sends users elsewhere.