HTTP redirects

twitter.com redirect chain

https://twitter.com/ 1 hop 42ms

Single hop, no redirects — landed at https://twitter.com/.

HTTP · 42ms · same-origin

1s ago

What this means

The hostname responded directly without a redirect. The status code in the chain table is the response from the final URL.

Chain 1 hop · 42ms total

1 HEAD 403 https://twitter.com/ 39ms

Check final URL

Run /check/twitter.com for live multi-region HTTP status.

Inspect TLS

Look at the cert at /ssl/twitter.com — particularly important if the chain crosses origins.

DNS

/dns/twitter.com shows the records driving the start of the chain.

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 monitoring regions (US East Virginia, US West Oregon, Europe London, Asia Singapore).
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: Direct probes from our monitoring infrastructure. We do not aggregate crowd reports, Twitter mentions, or DownDetector signals — every result on this page is a live network request.