Response header inspector

Methodology

Probe

We open a HEAD request to https://{host}/ (falling back to GET on 405 / 501), capture every response header, and grade the six load-bearing security headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. The overall letter grade is the average of those six.

Counts as DOWN

The HEAD (and GET fallback) request fails to complete, DNS, TCP, TLS, or timeout. Nothing to grade.

Counts as DEGRADED

Reserved for grade C / D, common security headers present but weakened, or some missing. The probe still returns full data; the grade reflects production-readiness.

Detail

We do not test for known CVEs, fingerprint application versions, or attempt downgrade attacks. The probe is a single request, what the server returned to a generic client. CSP grading is intentionally crude (penalises wildcard sources and 'unsafe-eval'); a manual review is the right move for fine-grained CSP work.

Cadence

Every 5 minutes, in parallel across 4 independent probe methods (HTTP/1.1 with strict TLS, HTTP/2, a browser User-Agent GET, and a curl-style HEAD) from our edge network. We check probe diversity, not geography — if a site blocks a non-browser User-Agent or only speaks HTTP/1.1, the four cards show it.

Rate-limited targets

If a host returns 429 or consistently drops connections from our IPs, we cap retries at 3 and report the last observed status, we do not flood the target to confirm the outage.

Data source

Our verdict is based on direct multi-method probes, every result above is a live network request, never a Twitter mention or DownDetector aggregate. User reports, when shown, appear separately below as a supplementary signal and are never used to determine the up/down verdict.

Related

• TLS certificate checker, pair with the headers check to see HSTS + cert together.
• Redirect chain checker, confirm where the headers actually land.
• DNS record checker
• Multi-method HTTP probe