HTTP redirects

Redirect chain checker

Follow every 301 / 302 / 307 / 308 hop from a hostname to its final destination. Surfaces scheme downgrades, cross-origin jumps, loops, and chains that exceed the 10-hop cap. Each hop is independently SSRF-guarded.

google.com wikipedia.org twitter.com t.co

Methodology

Probe
We open a HEAD request to https://{host}/ and follow Location headers manually, capping at 10 hops. Each hop is independently SSRF-guarded, redirects that point at private IPs are blocked, not followed. Falls back to GET when a server rejects HEAD with 405.
Counts as DOWN
The first request fails entirely (DNS, TCP, TLS, or timeout). Nothing in the chain to inspect.
Counts as DEGRADED
Reserved for warning-only conditions: scheme downgrade (https→http) on an otherwise valid chain, cross-origin chain, or final URL that isn't HTTPS.
Detail
We do not execute JavaScript, honor meta refresh tags, or follow Refresh: response headers, only HTTP-layer 301 / 302 / 303 / 307 / 308 redirects. Body content isn't fetched on intermediate hops; the final hop uses GET if we hit the cap, otherwise HEAD throughout.
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