What this website status checker shows
This is Host Check, the all-in-one check on HostChecker’s home page. It answers the first question anyone asks about a site, “is it up?”, and then shows the evidence. When you run a check, HostChecker asks for the site’s home page the way a browser does. It looks up the name, tries HTTPS first, and falls back to plain HTTP only if HTTPS does not answer at all. It asks with a HEAD request, which returns the status and headers without the page itself, and asks again with a normal GET if the server refuses HEAD. It follows redirects one at a time, up to 10, and times every request. Alongside that it reads the HTTPS certificate, looks up the name’s DNS records, pings the server, and tests what plain http:// does. What you get depends on whether you enter a domain name or an IP address.
For a domain name
Enter a domain and you get four tiles, a one-line explanation, and then the evidence in sections: where the name points, the redirect chain, where the time went, the response details, and anything worth noticing. Here is an example, with what each part tells you:
The server answered successfully. The site is up.
Where it points
Redirect chain1 redirect
- 52 ms301https://example.com/Moved Permanently → https://www.example.com/
- 180 ms200https://www.example.com/OK
Each step is one request: the status it returned and how long it took. A redirect says where to go next, and the check follows it, as a browser would. This one sends example.com on to the www name.
Where the time wentfinal response
The final request split into its stages: looking up the name, opening the connection, the HTTPS handshake, and waiting for the server to start answering. A stage that took no time is left out. A long Wait usually points at the server or the application behind it; a long Connect or TLS more often at distance or the network.
Response
What we noticed
- HTTPS works with a valid certificate (62 days left).
- Plain http:// redirects to https://.
- Served over HTTP/2.
A green tick is something done right. An amber ! is something worth fixing: a chain of three or more redirects, a slow first byte, plain http that does not redirect to https, or a certificate close to expiry.
For an IP address
Enter an IP address and the check does the same job without a name to look up. It connects to the address directly, so there is no DNS stage and no name-to-address records, and the “Where it points” section becomes “About this address”. Here is an example, with what each part tells you:
The server answered successfully. The site is up.
About this address
Request
- 95 ms200https://203.0.113.10/OK
What we noticed
- Served over HTTP/2.
- Nothing answers on port 80, so plain http:// links will not connect. Fine for an https-only site, but old http:// links and typed addresses will fail.
- The certificate does not name this IP address. That is normal when visiting by IP, since certificates are issued for domain names.
- Checked by IP address, so the server may answer differently than it does for its domain name (shared hosting and CDNs route by name).
The last line matters most. Many servers host several sites on one address and choose which to show by the name in the request. Asked by bare IP, they may show a default page, an error, or a different site from the one you expected. Check the domain name for the real answer.
Addresses on private or internal networks, such as 192.168.x.x or 10.x.x.x, are refused, and so are names that lead there. The check only connects to public hosts.
Either way, five things are worth knowing. The check runs from HostChecker’s server, in one place, so a site can look down from here and work for you, or the reverse. It asks for the home page only, so a working front page does not prove that login, checkout, or an API works. It reads the status and headers and does not download or draw the page, so it cannot see a blank page, a JavaScript error, or broken images. It follows only the redirects the server announces in its reply, not ones done by JavaScript or an HTML refresh tag. And it connects over IPv4 only and announces itself as HostChecker, so a site that blocks automated visitors may answer with an error that a browser would not get.
How to read the result
Above the details, a real result carries a one-line verdict. It is green when the final page answers with a 2xx code and nothing is wrong, amber for a 3xx that did not finish, a 4xx code, or an HTTPS connection that failed while plain http worked, and red for a 5xx code, no answer at all, a redirect loop, too many redirects, or a certificate that fails verification.
- HTTP status. The code of the final page.
2xxmeans success.3xxmeans a redirect, and it only ends up here when the chain stopped before reaching a page.4xxmeans the server is up and turned the request down:401wants a login,403refuses,404has nothing at the front page,410says it was removed on purpose,429means too many requests.5xxmeans the server failed:500an error building the page,502and504a proxy or gateway that got a bad answer or none from the server behind it,503overload or maintenance. A dash and “No response” means nothing answered. - Response time. How long the final request took, from looking up the name to the first byte of the reply. It leaves out earlier redirects, which show in the chain. Google’s web performance guidance treats a time to first byte of 0.8 seconds or less as good, though that figure also counts redirects, and this is a single request from a single place. Compare it with the same site on another day before reading anything into it.
- HTTPS certificate. Valid means the certificate passed verification for this name, and the sub-line shows days left and who issued it. Expired shows the date it ended. Invalid means browsers would warn: the name does not match, the certificate is self-signed, or the chain is incomplete. Not for this IP is the normal result when you check an IP. No HTTPS means nothing answered over HTTPS and only plain http did. A dash means no certificate was seen. For the dates, issuer, and chain in full, use the SSL Certificate Checker.
- Ping. Two small packets sent to the server that answered. A time and “2/2 replies” means it is reachable and shows the round trip. “No reply” is grey on purpose: many firewalls and cloud providers drop ping while the website works perfectly. The Ping test sends more packets. Ping is IPv4 only, and a dash means there was no IPv4 address to try.
- Where it points. The DNS answers for the name, so you can compare them with where you expect the site to be. For the full set of records, use the DNS Lookup.
- Redirect chain. Every request in order, with its status and time. One or two hops is normal, for example http to https, or the bare domain to www. Three or more earns an amber note, since each hop costs a round trip. If the same addresses repeat, or the chain is still going after 10 requests, the site has a redirect problem (see below). Browsers give up too: the Fetch standard stops at 20.
- Where the time went. The final request in stages: DNS, Connect, TLS, and Wait. Wait is the time from sending the request to the first byte coming back.
- Plain http://. The check also asks for the
http://address and reports whether it redirects to https, answers directly, or does not answer. This is only done when HTTPS worked. - What we noticed. Green ticks for things done right, amber marks for things to fix.
When the name does not resolve, there is nothing to connect to, and the result says so:
The name has no address record, or its DNS is broken. Check the spelling, then the domain’s A/AAAA records and nameservers (the DNS Lookup tool shows them).
Where it points
Request
- ERRhttps://nonexistent.example/Could not resolve nonexistent.example
Common problems and fixes
403 Forbidden, but the site works in my browser
A 403 means the server understood the request and refused it. Because this check is an automated visitor that announces itself as HostChecker, firewalls and bot-protection services, including the ones in front of many large sites, often answer it with a 403 or a 429 while real visitors get the page. Here the site is up, and the checker was turned away:
The server is up but refused this request. Common causes: a firewall or bot filter blocking automated checks, an IP block, or a locked-down directory.
If it is your own site and you want it to answer checkers like this one, allow the user agent or the checker’s address in your firewall or bot-protection rules. If it is not, a 403 here with a working browser tab usually just means bot protection.
5xx errors
The server was reached and reported a failure on its side. A 500 is an error in the application, so read its error log. A 502 or 504 comes from a proxy, load balancer, or CDN that got a bad answer or none from the server behind it, which usually means the application is stopped, crashing, or overloaded, so check that it is running. A 503 is overload or maintenance. Cloudflare’s own codes in the 520 to 526 range mean Cloudflare is in front of the site and could not get a good answer from the origin server behind it: 521 is a web server that is down, 522 a connection that timed out, 523 an origin that cannot be reached, 524 a timeout, 525 a failed TLS handshake, and 526 an invalid certificate on the origin. Fix it at the origin, not at Cloudflare.
No response at all
Nothing answered on port 443 or port 80. The cause can be a stopped web server, a firewall that blocks ports 80 and 443, a wrong address in DNS, or a host that is genuinely offline, and the check cannot tell a refused connection from a silent one. Look at the Ping tile and the Where it points section. If the server answers ping, the machine is online and the web server or the firewall is the likely problem. If the address in DNS is not your server’s, the name is pointed wrong, and the DNS Lookup shows the records.
The name does not resolve
Check the spelling and the ending first. Then confirm the domain is registered and active with WHOIS, and that the DNS provider holds a zone with an address record for the name. A freshly registered or freshly moved domain can take a while to settle, depending on the TTLs involved.
Redirect loop or too many redirects
The redirects send visitors in a circle, or the chain never ends, and browsers stop with a “too many redirects” error. Common causes: a www and non-www rule that point at each other, an http to https rule on a site that sits behind a proxy or CDN that connects to the origin over plain http (so the origin redirects again, forever), or a site address set wrongly in the application’s own settings. Follow the chain in the result and look for the step that repeats.
The certificate is expired or invalid
The server answers, but visitors would hit a full-page browser warning. The explanation under the tiles says which kind of fault it is: expired, issued for another name, self-signed, or an incomplete chain. Renew or reissue the certificate, and reload the web server so it serves the new one. The SSL Certificate Checker shows the dates and issuer, and our guide, SSL certificate expired: how to fix it fast, walks through renewing one.
HTTPS fails but plain http works
The site answers on http:// but nothing connects on https://. The result shows amber, and the certificate tile reads “No HTTPS”. Browsers try https first, so most visitors see an error. Check that the web server listens on port 443, that the firewall allows it, and that a certificate is installed for the name.
Plain http does not redirect to https
The site loads over https, but http:// either answers directly or does not answer at all. Anyone who types the bare name or follows an old http link then stays unencrypted or gets nothing. Add a redirect from http to https, and keep port 80 open so that the redirect can be served.
The site is slow
Use Where the time went. A long DNS stage points at the DNS provider. A long Connect stage points at distance or a congested network path, and the Traceroute shows the route. A long TLS stage is the HTTPS handshake. A long Wait means the server accepted the connection and then took its time to build the reply, which usually means a slow application, database, or an overloaded server. Run the check a few times: one slow result can be a cold cache or a busy moment.
Down for me, up here (or the reverse)
Because this check runs from one place, the two views can differ for real reasons: your own DNS cache still holding an old address, your internet provider or a firewall on your network, a regional outage, or a site that blocks some countries. If the check says the site is up and your browser disagrees, try another network, such as your phone off Wi-Fi, and clear or flush your DNS cache.
Frequently asked questions
How do I check if a website is down?
Type the domain into the box above and run the check. If the status is a 2xx code such as 200, the site answered and is up. A 5xx code, or “No response”, means it is down or broken. A 4xx code such as 403 means the server is up but refused the request. If the check says it is up and your browser says otherwise, the problem is likely on your side: try another network and clear your DNS cache.
What does a website status checker do?
It asks a website for its home page the way a browser would and reports what came back: the HTTP status code, any redirects, the HTTPS certificate, where the name points in DNS, whether the server answers ping, and how long each step took. It is a one-time check from one location, not a monitor.
What do HTTP status codes like 200, 301, 404, and 503 mean?
A 200 means success. A 301 or 308 is a permanent redirect and a 302 or 307 a temporary one. A 401 asks for a login, a 403 refuses the request, a 404 means nothing is at that address, and a 410 means it was removed on purpose. A 500 is an error on the server, a 502 or 504 means a proxy got a bad answer or no answer from the server behind it, and a 503 means the server is overloaded or down for maintenance. The first digit is the family: 2 success, 3 redirect, 4 the request was refused or wrong, 5 the server failed.
Why does it say 403 Forbidden when the site works in my browser?
Many sites use a firewall or bot-protection service that refuses automated visitors, and this check is one. The server is up, it just did not serve this request. If it is your site and you want checkers to see it, allow the HostChecker user agent or address in your firewall rules.
Is the site down for everyone or just me?
This check shows what one server in one place sees. If it reports the site up while you cannot reach it, the cause is probably local: your DNS cache, your network or internet provider, or a block in your region. If it reports the site down, that is strong evidence the problem is on the site’s side, but a site can also be unreachable from one network and fine elsewhere.
What does “No response” mean?
Nothing answered on port 443 (https) or port 80 (http), so the check could not get a status code. The usual causes are a web server that is stopped, a firewall blocking those ports, DNS pointing at the wrong address, or a host that is offline. The check cannot tell a refused connection from a timed-out one. The Ping tile helps: if the machine answers ping, it is online and the web server or the firewall is the likelier fault.
What is a good response time?
There is no single number, but Google’s web performance guidance treats a time to first byte of 0.8 seconds or less as good and more than 1.8 seconds as poor. The Response time here is for the final request only, from a single place, so use it to compare a site against itself over time and to see which stage is slow, not as a score.
Does the checker follow redirects?
Yes. It follows up to 10 redirects, one at a time, and shows every step with its status and time. It follows redirects the server announces in its reply, not ones done by JavaScript or an HTML refresh tag. A loop, or a chain still going after 10 steps, is reported as a problem. Browsers give up at 20 redirects.
Does it check the whole website or only the home page?
Only the home page, at the root of the name you enter. A healthy front page does not prove that every page, the login, the checkout, or an API works. It also reads the status and headers rather than loading the page, so it cannot see a blank page or a script error.
Can I check an IP address instead of a domain?
Yes. Enter an IPv4 address and the check connects to it directly. The certificate will usually not name the address, which is normal, and a server hosting several sites may answer differently by IP than it does for its name. Addresses on private or internal networks are refused. IPv6 is not supported.
Why does Ping say “No reply” when the site works?
Many firewalls and cloud providers drop ping on purpose, and a website does not need it. That is why a missing reply is shown in grey and not red. Our guide, why ping fails, goes through the other causes, and the Ping test sends more packets.
Is this an uptime monitor?
No. It checks once, when you ask, and keeps no history and sends no alerts. It is good for answering “is it up right now?” and for seeing why not. For ongoing monitoring you need a service that checks on a schedule from several places and notifies you.
Is the website status checker free?
Yes. There is no signup, no account, and no limit on how many sites you can check, apart from a per-visitor rate limit that keeps the service fast for everyone.