Website Status Checker
A website status checker sends one HTTP request to a URL and reports the status code the server returns. Codes 200–399 count as up; 400–599 or a connection timeout count as down. Checking https://example.com here returns 200 OK in a few tens of milliseconds, so the site is answering for us, not just for you.
HTTP status codes and what this checker reports
| Code | Reason phrase | Verdict here | What it means for your check |
|---|---|---|---|
| 200 | OK | Up | The server answered normally. Nothing to fix. |
| 301 | Moved Permanently | Up | Permanent redirect. This tool does not follow it, so you see 301 plus the Location header. |
| 302 | Found | Up | Temporary redirect, often to a maintenance, login or geo-routing page. |
| 304 | Not Modified | Up | A cached copy is still valid. Only returned when the request carries validators. |
| 403 | Forbidden | Down | The server answered, so the host is reachable and this is not an outage. A WAF, bot filter or IP allowlist refused this client; the verdict still reads Down because 403 is a 4xx code. |
| 404 | Not Found | Down | The host answered, so it is reachable — only the path you asked for is missing. Test the bare domain next. |
| 429 | Too Many Requests | Down | Rate limiting: too many requests in a short time. If the response carries a Retry-After header, wait until the moment it names — either a number of seconds or an HTTP date — before retesting. |
| 500 | Internal Server Error | Down | The application crashed on the origin. Read the origin error log. |
| 502 | Bad Gateway | Down | A proxy or CDN could not reach the origin, often mid-deploy. |
| 503 | Service Unavailable | Down | Overload or planned maintenance. Temporary by definition; check Retry-After. |
| 504 | Gateway Timeout | Down | The origin took longer to answer than the proxy was willing to wait. |
| 0 | No response | Down | Nothing answered: DNS failure, refused connection, invalid TLS certificate, or the request ran out of time — 8 seconds to establish the connection, 15 seconds in total. |
Verdicts follow the status classes in RFC 9110: 200–399 is reported as up, 400–599 as down. The verdict describes the URL you typed, not the machine behind it — a 403 or a 404 means the server answered, so the host is reachable and neither is an outage. A 304 counts as up because the resource exists; a 404 counts as down because the requested URL does not.
Is the website down or is it just me?
The check above runs from our server, not from your browser, which is exactly what makes the comparison useful. If this page reports 200 OK while your browser shows a connection error, the outage is local to you: a DNS resolver that has cached a dead record, a VPN or corporate proxy, an entry in your hosts file, or an ISP routing problem. If both fail, the origin or its CDN is genuinely down and there is nothing to fix on your machine.
Why do websites go down?
Most outages fall into six families, and the status code tells you which one you are looking at:
- Expired or mismatched TLS certificate — the connection fails before HTTP starts, so you see status 0.
- DNS records changed or expired: the hostname no longer resolves, again status 0.
- The application process crashed or ran out of memory — 500 from the origin, 502 from the proxy in front of it.
- Traffic beyond capacity, or a deliberate maintenance window — 503, usually with Retry-After.
- A slow database or cold start that overruns the proxy timeout — 504.
- A provider incident at a CDN, cloud region or registrar, which can take thousands of unrelated sites down at once.
What should I do if my website is down?
Work from the outside in, in this order:
- Run the check here to confirm the failure is not local to your network.
- Read the code. 0 means DNS or TLS; 5xx means the origin; 403 means a firewall rule; 404 means the wrong vhost or path.
- Open the Response Headers list — Server, Location and Retry-After name the layer that answered you.
- Check your hosting provider and CDN status pages before you open a support ticket.
- Re-run the check after each change and export the CSV so the incident ticket carries timestamps instead of screenshots.
How fast should a website respond?
The response time shown is the round trip our server needed for a single HEAD request: DNS lookup, TCP connect, TLS handshake and the server's first answer. It excludes images, CSS, JavaScript and rendering, so it is far lower than a Lighthouse page-load figure. The colour bands used on this page are:
| Response time | Colour | Reading |
|---|---|---|
| < 500 ms | Green | Healthy. Typical for a CDN edge or a warm cache. |
| 500–1500 ms | Yellow | Acceptable but worth watching: usually an origin round trip with no edge cache. |
| > 1500 ms | Red | Slow. Check origin CPU, database queries, cold starts and cross-continent routing. |
About Website Status Checker
A website status checker answers one narrow question well: did the server answer, and what did it say? This tool opens a single HTTP HEAD request to the address you type, allows 8 seconds to establish the connection and 15 seconds for the whole request, and reports four things — the numeric status code, the round-trip time in milliseconds, the Content-Type and the Server header — plus the complete list of response headers the origin sent back.
Two design choices make the reading unambiguous. First, redirects are not followed. If example.com answers 301, you see 301 and its Location header rather than the status of some other page three hops away; that is what you want when you are verifying an HTTP-to-HTTPS or non-www rule. Second, the up/down verdict follows the status classes defined in RFC 9110: 200 to 399 is reported as up, 400 to 599 as down, and a status of 0 means the request never completed at all — DNS did not resolve, the connection was refused, the TLS certificate failed validation, or the origin ran past the timeout.
The check runs from our server rather than from your browser, which is why it settles the "is it down or just me?" question. If your laptop cannot load a site but this page reports 200 OK, the fault is local: your resolver, your ISP, a VPN, a corporate proxy or a stale hosts entry. If both fail, the problem sits at the origin or in its CDN.
Bulk mode accepts up to 10 addresses, one per line, and checks them in sequence with a 300 ms pause between requests so a single run cannot exhaust the 60-checks-per-minute quota. The results come back as a compact list you can download as CSV or copy as a tab-separated table straight into a spreadsheet or an incident ticket. Every check also produces a shareable link that re-runs itself when a colleague opens it, so an outage report arrives with evidence attached instead of a screenshot.
One caveat worth remembering: requests leave a datacenter IP with the user agent FreeWebTools Status Checker/1.0. Sites behind aggressive bot filtering may answer 403 to us while serving browsers normally, so read a 403 as "refused this client", not automatically as "down".
Use Cases
How to check whether a website is down
Leave the Single URL tab selected and type the address you want to test, for example example.com; the https:// prefix is added for you if you omit it.
Press Check Status. One HTTP request leaves our server and the verdict banner reads Website is UP for codes 200–399, or Website is DOWN for 400–599 and timeouts.
Read the four tiles: Status Code, Response Time, Content Type and Server. Response times under 500 ms show green, above 1500 ms red.
Open the Response Headers list to see everything the origin sent, including Location on a 301 and Retry-After on a 429 or 503.
Switch to Bulk Check to paste up to 10 URLs, one per line, then use Download CSV or Copy as table to keep the run.
Use Copy shareable link to send a URL that re-runs the identical check when a colleague opens it.
Pro Tips
- Test the bare domain and the www version separately. example.com and www.example.com often resolve to different hosts, and only one of them may be failing.
- Status 0 is not a 500. It means nothing answered at all, so check DNS resolution and TLS certificate expiry before you blame the application.
- Response times under 500 ms show green, 500–1500 ms yellow and slower than 1500 ms red. The figure is server round trip only — no images, CSS or JavaScript.
- If you get 403 from here but the site loads in your browser, a WAF is filtering datacenter IPs or our FreeWebTools Status Checker/1.0 user agent. That is not an outage.
- Bulk mode is capped at 10 URLs and the API allows 60 checks per minute per IP. Split longer lists into batches instead of retrying into a 429.
Troubleshooting
The check returns status code 0 and no headers.
Nothing answered. The hostname may not resolve, the connection may have been refused, the TLS certificate may be expired or issued for a different name, or the request may have run out of time — 8 seconds to connect, 15 seconds in total. Verify DNS and the certificate first, then try the http:// version to isolate a TLS fault.
We report 403 Forbidden but the site loads fine in a browser.
A WAF or bot-protection rule is blocking datacenter IPs or the FreeWebTools Status Checker/1.0 user agent. The site is up; it is refusing automated clients. Allowlist the check or confirm from a residential connection.
Bulk mode stops halfway with a rate-limit message.
The API allows 60 checks per minute per IP address. Wait sixty seconds and re-run the remaining URLs, or split the list into smaller batches. The run already spaces its requests 300 ms apart.
A page that works in the browser reports 404 here.
You are probably testing a path that does not exist on that host, or the domain resolves to a default virtual host. Test the bare domain first and add the path once the root answers 200.
Frequently Asked Questions
Type the address into the box above and press Check Status. The tool sends one HTTP request from our server and reports the status code, the response time and every response header. A code between 200 and 399 means the site is up; 400 to 599, or a status of 0, means it is down. The response time shown is the round trip our server needed, not your browser's — DNS lookup, TCP connect, TLS handshake and the first answer — often a few tens of milliseconds for a nearby origin.
This checker runs from our server, not your browser, so comparing the two results locates the fault. If we report 200 OK and you still cannot load the page, the problem is on your side: DNS cache, VPN, proxy, browser cache or hosts file. If we also report a 502 or a timeout, the fault is at the site's end rather than yours — though a geo-block or a firewall rule aimed at our IP looks the same from here.
503 Service Unavailable means the server is reachable but is refusing to serve the request right now, usually because of overload or planned maintenance. It is temporary by definition and often carries a Retry-After header saying when to come back. Search engines treat a short 503 as "come back later" rather than as a permanent failure.
In practice: expired or mismatched TLS certificates and broken DNS records (both show as status 0), an application that crashed or ran out of memory (500), a proxy that cannot reach the origin mid-deploy (502), traffic beyond capacity or maintenance (503), a database slower than the proxy timeout (504), and provider-wide CDN or cloud incidents.
Confirm here first that the failure is not local to your network. Then read the code: 5xx means look at your origin logs and process manager, 0 means check DNS and certificate expiry, 403 means a firewall or WAF rule, and a 404 on the bare domain means the wrong virtual host. Check your provider status page before opening a ticket.
Yes. Switch to the Bulk Check tab and paste up to 10 URLs, one per line. They are checked in turn with a 300 ms gap between requests, and the results appear as a list with verdict, status code and response time. You can then download the whole run as CSV or copy it as a tab-separated table.
No, and that is deliberate. Redirects are left unfollowed so a 301 or 302 is reported exactly as the server sent it, together with its Location header — which is what you need when verifying an HTTP-to-HTTPS or non-www rule. To trace a whole redirect chain hop by hop, use our redirect checker instead.
Because the request arrives from a datacenter IP with the user agent FreeWebTools Status Checker/1.0. Bot-protection services, WAFs and CDN firewall rules routinely answer automated clients with 403 Forbidden or a challenge page while serving real browsers normally. A 403 from this tool therefore means "refused this client", not always "down".
It is the time our server needed to complete a single HEAD request, in milliseconds, including DNS lookup, TCP connect and the TLS handshake. It excludes images, CSS, JavaScript and rendering, so it is far lower than a Lighthouse page-load score. Compare runs against each other, and expect 100–300 ms extra for a distant origin.
No. The endpoint rejects the hostnames localhost, 127.0.0.1, 0.0.0.0 and ::1, any IP literal in a private or reserved range such as 192.168.x.x or 10.x.x.x, cloud metadata addresses like 169.254.169.254, and sensitive ports including 22, 3306 and 6379. A hostname is resolved once and refused if that IPv4 address is private; the check is IPv4-only, so treat it as a guard against server-side request forgery rather than a guarantee. Test internal hosts with curl from inside the network.
Sources and standards
The five status classes and the meaning of each individual code come from the HTTP specification and the IANA registry below. The MDN and Google Search Central pages are documentation rather than specifications, and 429 Too Many Requests is defined in RFC 6585, not in RFC 9110. The up/down verdict is our own reading of those class boundaries: this page treats 200–399 as up and 400–599, or a request that never gets a status code at all, as down.
- RFC 9110, HTTP Semantics, section 15 — the normative definition of every status class.
- IANA HTTP Status Code Registry — the authoritative list of assigned codes.
- MDN HTTP response status codes — practical notes for each code.
- Google for Developers, “How HTTP Status Codes Affect Google’s Crawlers” — what each code means for crawling and indexing.
- Google for Developers, “Debug Network and DNS Errors for Google’s Crawlers” — what it means when a request never gets a status code back.
- RFC 6585, Additional HTTP Status Codes, section 4 — the definition of 429 Too Many Requests and its Retry-After hint.