All tools

HTTP status checker

Enter a URL and read back every hop it goes through. The status code, where it points next, how long it took and the response headers at each step.

Check a URL

Include http:// or https://. The request comes from our server, so the address has to be reachable from the public internet.

Enter a URL above. Every hop comes back with its status, where it points and how long it took.

Our server makes this request, not your browser. We identify ourselves as SessionReplay-Tools, follow at most five hops and give up after twenty seconds.

What a redirect chain is

A redirect chain is everything that happens between the URL somebody typed and the page they finally see. Each hop answers with a 3xx status and a Location header naming the next URL, and the browser follows it. One hop is normal. Three or four usually means old rules have been layered on top of each other, and every extra hop costs a round trip before anything renders. This checker walks the chain from our server and shows each step with its status, the destination it named, how long it took and the headers it sent back.

Why a chain that ends in the wrong place reaches you late

A redirect that lands somewhere unexpected rarely looks like an error. The visitor gets a page, just not the one they asked for, so nothing is logged and nobody files a ticket. It reaches you second hand, as a complaint that a link is broken or that signing in sends people to the wrong place. Reading the chain turns that into something specific: the hop that changed the host, dropped the path, or sent an old campaign link to the home page.

What 301, 302, 307 and 308 promise

301 says the move is permanent and the old URL should be forgotten, which is what search engines act on. 302 says the move is temporary and the original URL stays the canonical one. Both were widely implemented as turning a POST into a GET, which is why 307 and 308 exist: 307 is the temporary redirect that keeps the method and the body, and 308 is the permanent one that does the same. If a form submission loses its body somewhere in a chain, the status code on that hop is usually the reason.

Questions about redirect chains

Yes. It follows up to five hops and reports every one of them, including the final response. Each hop shows its status, the Location header it sent, the address it resolved to, how long it took and the full response headers. Your browser follows the same chain silently and only shows you where it ended.

Our server makes the request, so it carries no cookies, no session and no history with the site. A page that redirects a signed-in visitor to a dashboard will redirect us to the sign-in page instead. Geography, content negotiation and bot rules can change the answer too: we send SessionReplay-Tools as the user agent, and some sites treat that differently from a browser.

A loop is a chain that comes back to a URL it has already visited, so it never reaches a final response. Browsers give up after a fixed number of hops and show an error rather than following it forever. The usual cause is two rules that undo each other, such as one adding a trailing slash and another removing it, or an http rule and an https rule pointing at each other.

Because the request comes from our server, with no cookies and no credentials. A page that needs a session answers us the way it answers any stranger, which is usually a redirect to a sign-in page. That is still worth knowing: it is exactly what an unauthenticated visitor gets. To see the chain a signed-in visitor gets, you need the request as it happened in their browser, which is what Session Replay captures.

A chain that ends somewhere unexpected is a bug report

Session Replay captures the page, the network log and the console beside it, so the next person to look at a redirect that went wrong already has the whole request in front of them.