HTTP Header & Status Monitoring

Security headers like HSTS, Content-Security-Policy, X-Frame-Options, and Referrer-Policy are often configured at the web server or CDN layer. When a server is updated, a CDN configuration is changed, or traffic is routed differently, these headers can disappear without warning — removing protections that were silently preventing clickjacking attacks, mixed content, and cross-site scripting.

Redirect chains are equally fragile. An HTTP → HTTPS redirect that adds an extra hop, a www to non-www redirect that was dropped during a migration, or a canonical URL redirect that now points to the wrong destination — all are invisible to uptime monitoring but detectable with header inspection.

The cost of missing these regressions is rarely immediate, which is exactly what makes them dangerous. A dropped CSP header doesn't trigger an outage — it just quietly removes a layer of defense until the day an attacker relies on its absence. A broken canonical redirect doesn't 500 — it just bleeds search ranking and sends a fraction of visitors to the wrong page for weeks before anyone notices.

NetTests fetches your configured URLs on a schedule and captures every response header exactly as your server or CDN sent it, without normalization that could mask a misconfiguration. Each header's value is compared against the previous successful check, and any addition, removal, or change is recorded as an explicit diff rather than a vague "something changed" notice.

Redirect chains are followed end to end: NetTests records every hop from the initial request to the final destination, including the status code and Location header returned at each step. This catches an extra hop introduced during a migration, a redirect loop, or a canonical URL that silently started pointing somewhere unexpected — all conditions that a simple "did it return 200" check would miss entirely.

Alerts reach your team through email, Slack, Microsoft Teams, or SMS — choose any combination per monitor, and decide whether a single failed check should fire an alert or whether NetTests should wait for a failure to repeat across a configurable number of consecutive checks first. The dashboard lists every monitored URL with its current header set and status code, and lets you open any past check to see exactly what changed and when. Time to first alert is typically under a minute from the moment a check fails.

Failure conditions are configurable per monitor and per header. You can require an exact header value, flag any change in either direction, or alert only when a specific header disappears entirely — useful for a header like CSP, where the precise policy may evolve over time but its presence is non-negotiable. Status code rules work the same way: treat the whole 2xx range as healthy, or pin a monitor to one exact code if your endpoint's contract requires it. Every check result, including the full header set and status code observed, is retained so you can reconstruct exactly what a URL was serving at any point in its history.