Skip to main content

HTTP header & redirect checker

Follow a URL hop by hop and read what comes back: every redirect in the chain, the status code it finally answers with, and the headers it sends. The same walk an uptime check makes, without your browser's cache, cookies or edge server in the way.

GET from our probe · up to 10 hops · headers only, never the body · nothing stored

Enter a URL to walk its chain.

What each redirect code means

The number is not decoration. It tells a client whether to remember the new address and whether the request method survives the jump, and getting it wrong is how a working form starts losing data.

codecached by clientsmethod survivesuse it for
301 moved permanently yes, aggressively no, POST usually becomes GET An address that is never coming back. Hard to undo: browsers keep it.
302 found no no, POST usually becomes GET A temporary move. The default most frameworks emit, and the safe one while you are still deciding.
303 see other no no, always becomes GET After a form submission, so a refresh does not submit twice.
307 temporary redirect no yes A temporary move where a POST must stay a POST.
308 permanent redirect yes yes A permanent move for an API, where turning POST into GET would break callers.

Why the chain is worth reading

A monitor records the answer at the end of the walk, so a chain that works is invisible and a chain that breaks looks like the site being down. The two failures that hide in there are a loop, where a CDN forces HTTPS while the origin sends HTTPS back to HTTP, and a hop that quietly leaves the host you started on, which drops cookies and authorization headers on the way.

Length costs you too. Every hop is a fresh connection, a fresh DNS lookup and, on HTTPS, a fresh handshake. Three redirects in front of a homepage is most of a second before the first byte of real content, paid by every visitor and every check.

This checker validates the certificate at each hop, the way a monitor does, so a TLS failure here is a real one. When you need to read a certificate that is already expired or self-signed, the SSL certificate checker reads it without validating. If the name itself is the problem, the DNS lookup compares two resolvers, and what ICMP, TCP and HTTP each prove covers which layer a failure actually sits on.

FAQ

What causes ERR_TOO_MANY_REDIRECTS?
Two rules that each think the other should have finished the job. The classic pair is a CDN forcing HTTPS while the origin redirects HTTPS back to HTTP, so the chain bounces between the two forever. The hop list above shows the cycle: look for the same URL appearing twice.
Which redirect codes keep the request method?
307 and 308 preserve it, so a POST stays a POST. 301 and 302 do not guarantee that, and in practice almost every client turns them into a GET. 303 always becomes a GET. If a form submission breaks only after a redirect was added, this is usually why.
Why does my browser show something different?
A browser answers from its own cache, sends your cookies, and may have been handed a different edge server than we were. The first request of a session is the honest one, and that is what this runs: no cookies, no cache, a fresh connection each time.
The check fails here but the site loads for me. Why?
Usually the certificate. This checker validates the chain the way a monitor does, so an expired certificate or a missing intermediate fails outright, while your browser may paper over it from cache. The SSL certificate checker reads the certificate without validating it, which is the tool for that case.
Should an uptime monitor follow redirects?
Follow them when you are watching whether people can reach the site, because that is the journey they take. Turn following off when you are watching a specific endpoint and a redirect would mean something has changed: an API route that starts answering 302 is an incident, not a success.
Which response headers matter for uptime?
The status code first, then anything that explains a bad one: Retry-After on a 429 or 503, cache and edge headers that say whether a CDN answered instead of your origin, and Location on a redirect. Security headers such as HSTS do not affect uptime, but the chain that sets them often does.

Watch the chain, not just the homepage

An HTTP check walks these hops every minute from every region you enable, and tells you when the status at the end of them changes.

start free

more free tools: uptime SLA calculator · cron expression generator · error budget calculator · incident message generator · DNS lookup · SSL certificate checker · the whole set