HTTP status checker:
what does your URL return?
Enter any URL — the checker follows every redirect hop by hop, times each one, and translates the status code and response headers into plain English.
Everything one request can tell you
A single GET returns the status code, redirect chain, headers and timing. We read all four.
The status code
The three digits that decide everything: 200, 301, 404, 500. Read from the wire, with soft-404s and error pages called out.
is it working?The redirect path
Every hop from the URL you typed to the page that finally answers — status, target and latency for each link in the chain.
where does it go?The headers
Caching, compression, security policies, server fingerprints — the response headers, each one translated into what it means for you.
is it configured?The timing
Time to first byte for every hop, and the total a visitor pays before real content starts. Redirects are where the seconds hide.
why is it slow?200, 301, 302, 404, 500 and 503
HTTP defines dozens of status codes. These six are the ones you meet day to day.
The one you want: the server understood, found it, returned it. Watch for 200s that are secretly error pages — “soft 404s” fool every naive check.
A permanent move. Browsers cache it aggressively and search engines transfer the page’s authority to the new URL. The right code for http→https and renamed pages.
A temporary detour: nothing gets cached, no authority moves. Fine for A/B tests and logins — wrong for migrations, where it quietly wastes crawl budget forever.
Nothing lives at this URL. Fine for genuinely dead pages — a conversion killer when a typo or a broken redirect chain sends real traffic there.
The server itself failed — an unhandled exception, not a missing page. The intermittent ones are the killers: you’ll almost never catch them by hand.
“Temporarily down” — the correct answer during maintenance, ideally with a Retry-After header so crawlers come back later instead of de-indexing you.
Redirect chains accumulate over years
Nobody designs a four-hop chain. They accumulate — the https migration in 2019, the www switch in 2021, the storefront move last spring. Each one made sense; together they’re a tax on every visit:
- Every hop is a full round trip — and a new hostname adds a DNS lookup and a TLS handshake on top.
- A 302 in the chain means browsers re-ask every single time — the chain never gets cached away.
- A plain-HTTP hop mid-chain sends the request unencrypted — cookies and paths included.
- Search engines follow long chains reluctantly — and every extra hop dilutes what the link is worth.
Chain patterns, diagnosed
what we flag · whyCheck it yourself with curl
Everything this page does has a one-liner equivalent. We run them all at once and translate the output.
Common questions
Type it above — the verdict leads with the final status code, plus every redirect it took to get there. (“Status code” and “response code” are the same thing: the three-digit number in the first line of the HTTP response.) On the command line: curl -s -o /dev/null -w '%{http_code}' yoururl. Free, no sign-up.
301 says “moved permanently”: browsers cache the redirect and search engines transfer the old URL’s ranking authority to the new one. 302 says “temporary detour”: nothing is cached, nothing transfers — the old URL keeps competing with the new one indefinitely. Use 302 only when the move genuinely is temporary (A/B tests, geo-detours, login bounces). Migrations, https upgrades and renamed pages should always be 301.
Zero or one is ideal; two is forgivable; three or more is worth fixing. Every hop costs a full round trip, and a hop to a new hostname adds a DNS lookup and a TLS handshake. On a mobile network each of those can be hundreds of milliseconds. Browsers give up entirely at 20 hops. The fix is almost always the same: point every legacy entry URL directly at the final destination, in one 301. Skip the whole history of your site moves.
Three usual reasons. Your browser has a stale 301 in its cache: permanent redirects are cached aggressively, so a fixed redirect can keep “happening” locally for weeks. Or the site serves different redirects to different user-agents — try the Googlebot or iPhone option above and compare. Or the redirect isn’t HTTP at all. Meta-refresh tags and JavaScript redirects fire after the page loads, which curl never sees. We flag those on the final page.
503 Service Unavailable with a Retry-After header — never a 200. A maintenance page that returns 200 tells search engines “this is the content now”, and they may index it or drop your real pages. 503 says “temporary, come back later”, which is exactly what crawlers do. If you schedule maintenance windows in a monitoring tool, alerts pause while the 503 is expected.
The short list: strict-transport-security (HSTS — browsers skip the http:// hop entirely), x-content-type-options: nosniff, a deliberate cache-control, and compression (content-encoding: br or gzip). Also worth checking what you’re leaking: a Server header with a full version number is free reconnaissance for vulnerability scanners. The header card in every result grades all of these.
That is what uptime monitoring is. Uptimia requests your URLs on a schedule you set — every 5 minutes by default, down to every 10 seconds — and follows redirects the way this tool does. When the response stops being what you expect, you get an alert: a 200 that becomes a 500, a chain that starts looping, a certificate hop that fails. A failing check is confirmed by up to three more probes on other continents before you are paged. One thing it does not watch is the shape of a healthy chain: a 301 that becomes a 302, or a chain that grows a hop while still ending in 200, is not an outage and raises no alert — that is what this page is for.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.