Free Website Status Checker

There's a small ritual every developer knows. A page won't load, and before you panic you ask the one question that decides everything you do next: is it down for everyone or just me? It matters because the two answers send you in opposite directions. If the site is genuinely down, there's nothing to fix on your end and you wait or raise the alarm. If it's just you, the problem is sitting on your side of the wire and no amount of refreshing the real server will help.

The catch is that your own machine is the worst place to judge from. A stale DNS entry, a half-connected VPN, an ISP hiccup, an extension gone rogue, or a cached error page can all make a perfectly healthy site look dead to you and nobody else. That's exactly why 'is it down for everyone or just me' became a genre of tool in the first place — you can't trust the verdict from the one browser that might be the actual culprit.

So here's how to check if a website is down without fooling yourself: hit it from somewhere that isn't your laptop. That's what the checker above does: it sends a fresh request to the URL from our servers, with no cache and none of your local baggage, and tells you what comes back. If it answers for us but not for you, the fault is local — flush your DNS, drop the VPN, try another network. If it doesn't answer for us either, it really is down, and now you know it's the site and not your setup.

Every time a server answers a request it stamps the response with an HTTP status code — a three-digit number that says, in the server's own words, how things went. The tool shows you that exact code instead of a vague up-or-down, and once you can read the families you can tell a healthy site from a broken one at a glance. The first digit is the whole story: 2 is success, 3 is a redirect, 4 is your request's fault, 5 is the server's fault.

Redirects are where 'the site is up' and 'the site is working' quietly part ways, and the whole HTTP 301 vs 302 question comes down to a single word: permanence. A 301 says 'this page has moved for good, update your bookmarks.' So what is a 302, then, and what does a 302 mean in practice? It's a temporary redirect — 'the page is over here for now, but keep asking at the original address.' Same visible result in a browser, completely different promise about the future.

That promise is the part search engines act on. When you 301 redirect a page, Google treats it as permanent and passes the old page's ranking signals to the new URL — which is why, when you genuinely move content, a 301 is what you want. Leave a 302 in place on a move that was actually permanent and you can strand your rankings on a URL you've abandoned, because Google keeps crediting the old address. (If you need the strict, method-preserving versions, 307 and 308 are the modern equivalents of 302 and 301.)

The redirect chain in the results above is where you verify all of this. It lists every hop with its status code, so you can confirm the boring things that should be true — http redirects to https, the bare domain redirects to www or the other way, and a moved page returns a 301 and not an accidental 302 — instead of assuming they are.

Sometimes the chain doesn't end. The browser follows hop after hop, eventually gives up, and throws the too many redirects error — ERR_TOO_MANY_REDIRECTS in Chrome, a blank wall to your visitor. It's one of the more maddening failures because the server is technically responding every time; it's just responding with 'go somewhere else' forever.

So what is a redirect loop? It's when A sends you to B and B sends you straight back to A, and the two bounce the request between them until the browser caps out. A handful of misconfigurations cause almost all of them: an http-to-https rule fighting a https-to-http rule, a www versus non-www mismatch where each version redirects to the other, or a CDN like Cloudflare set to 'Flexible SSL' in front of a host that's already forcing HTTPS. The common thread behind too many HTTP redirects is always two rules that each think they get the last word.

This is the failure the redirect chain view is best at exposing. Because it lays out every hop in order with its status code, redirect loops stop being invisible — you'll see the same two URLs ping-ponging back and forth right up until the chain caps out, and the exact pair that's fighting is sitting there in plain sight.

Everything above tells you how a site is answering at the exact second you press check. That's genuinely useful for debugging, but it's the wrong tool for the real question, which isn't 'is it up now' — it's 'was it up at 3am on Sunday, and did anyone find out before the customers did.' A manual check can't be standing there at 3am. Downtime almost never announces itself; the first signal is usually an annoyed message from someone who hit the site before you did.

That's the gap continuous monitoring closes. Point Uptura at the URLs you care about and it runs this same check around the clock — status code, response time, and the full redirect chain — and because 'up' isn't always up, you can require a keyword or a specific status code so a server quietly serving a broken 200 still counts as down. The instant a check fails, confirmed across consecutive runs to rule out a blip, Uptura emails or Slacks your team, then tells you again the moment it recovers. Free during our public beta, no credit card — so the next outage is something you catch in minutes, not something you apologise for later.