Is My Website Down? Website Down Checker That Tells You If Your Site Is Up or Down, and Which Layer Broke
We request your site from outside your network and test the four things that have to work in the order they fail: the domain resolves, something accepts the connection, the certificate is valid, the application answers. Then we name the layer that broke.
Website down checker
LiveOne domain at a time. Takes a few seconds.
How to tell whether your website is down
To find out whether your website is down, request it from outside your own network and check each layer in the order a failure cascades: DNS, then the TCP connection, then the TLS handshake, then the HTTP status code. A site is genuinely down when any one of those four fails, and the layer that fails first tells you where the fix is. Reloading the page in your own browser cannot answer the question, because your browser has cached DNS, a session cookie and possibly a service worker that all hide the real state of the server.
Most down checkers return one word. That word is the least useful part of the answer, because you already suspected it before you opened the tool. The question worth answering is which of the four layers failed, since each one is owned by a different system, fixed by a different person, and completely unaffected by the fix for the other three. Restarting a web server does nothing for an expired domain, and renewing a certificate does nothing for a 500.
What this checker runs, in order
- 1. DNS The same lookup against Google Public DNS, Cloudflare, NextDNS and our own node, so disagreement between resolvers becomes visible.
- 2. TCP A real connection to port 443 or 80, timed, so refused and timed out are told apart.
- 3. TLS The handshake, the expiry date, the hostnames on the certificate and whether the chain verifies against a public trust store.
- 4. HTTP Every redirect hop and the final status code, with the time split into connect, handshake and first byte.
Fault attribution
The four layers a website fails at, and who owns each one
A visitor experiences one thing, a site not loading, and that single symptom has four completely separate causes. They fail in a fixed order, and a failure at any layer makes every layer above it untestable: if the domain does not resolve there is nowhere to send a request, so nothing can be learned about the server. That is why a checker that only reports the HTTP status cannot distinguish a dead domain from a crashed application. Both come back as no response.
| Layer | What has to work | How it fails | What a visitor sees | Where the fix is |
|---|---|---|---|---|
| DNS | A resolver can turn your domain name into an IP address | Domain expired, nameservers not answering, A record deleted or edited, registrar lock or transfer in progress | A "server not found" or "site cannot be reached" error, with no page at all | Your registrar and your DNS zone. Nothing on your server can fix this. |
| TCP | Something accepts a connection on port 443 or 80 at that address | Web server stopped, firewall rule dropping or rejecting traffic, the host itself powered off, security group closed | A long hang followed by a timeout, or an instant connection refused | Your host, your firewall and your web server process. The application has not run yet at this point. |
| TLS | The handshake completes and the certificate verifies for this hostname | Certificate expired, issued for a different name, self signed, or the intermediate certificate is missing from the chain | A full page browser warning that most visitors will not click through | Your certificate and its renewal. The server is running perfectly and still serving nobody. |
| HTTP | The application returns a usable status code | 500 from an unhandled exception, 502 or 504 from a proxy in front of a dead or slow app, 403 from a firewall rule, 404 from a broken route | An error page, a blank page, or a spinner that never resolves | Your application code, its database and its dependencies. |
The TLS row is the one people underestimate. A certificate that expired at 2am leaves the domain resolving correctly, the server accepting connections and the application returning a healthy 200, and every browser still refuses to show the page. By every measure except the one that counts, the site is up. The SSL certificate checker covers that layer on its own, including the chain and the renewal window.
The most searched version of this question
Is my website down or is it just me?
Your browser is the worst available instrument for this measurement, and it is the one everybody reaches for first. It holds state that the rest of the internet does not share, and that state makes it disagree with reality in both directions: it will show you a working page after the server has died, and a dead page after the server has recovered. Here is every mechanism that causes it, and how to rule each one out.
| Why your browser disagrees | The mechanism | How to rule it out |
|---|---|---|
| Your resolver still has the old address cached | A DNS answer is cached for its TTL. Until that expires, your machine keeps using the address it already has and never asks again, so a moved or deleted record is invisible to you and obvious to everyone else. | Check the same domain against several public resolvers. The checker above queries four. |
| Your resolver has cached the absence of a record | Negative answers are cached too. If you look up a domain before its record exists, the "no such name" answer sticks around, which is why a domain you just fixed still reports as missing for you alone. | Wait out the negative cache or query a resolver that has not seen the failure yet. |
| HSTS is forcing HTTPS | Once a browser has seen a Strict-Transport-Security header it refuses plain HTTP for the whole max-age, commonly 31,536,000 seconds, which is one year. A TLS problem therefore shows as a hard failure with no option to continue. | Test with curl, which has no HSTS memory of its own. |
| You are logged in and anonymous visitors are not | Session cookies, preview modes and staging cookies routinely expose pages that the public cannot see. A checker sends no cookies, which is exactly why it can disagree with you. | Open the site in a private window, or use a checker. |
| A service worker is serving a cached copy | A progressive web app can keep rendering a fully functional page from cache long after the origin has stopped responding. The site looks alive to returning visitors and dead to new ones. | Hard reload with the cache disabled in DevTools, or check from outside. |
| Your network is the problem, not the site | Corporate DNS filtering, a captive portal, an ISP outage or a local firewall rule all produce a failure that follows you and nobody else. | Try mobile data, or check from a node that is not on your network. |
How long a wrong DNS answer survives
A resolver keeps an answer for the TTL that was attached to the record when it fetched it. Lowering the TTL now does not help the resolvers that already cached the old value, which is the single most common misunderstanding during a migration. The worst case is the full old TTL, counted from a moment you cannot observe.
| TTL on the old record | Worst case staleness | What that means in practice |
|---|---|---|
| 60 seconds | 1 minute | Aggressive. Used ahead of a planned migration so the change lands almost immediately. |
| 300 seconds | 5 minutes | A common default for records that change. Short enough to fix a mistake inside a coffee break. |
| 3,600 seconds | 1 hour | The most common value on records nobody expected to change. An hour of split reality during an incident. |
| 14,400 seconds | 4 hours | Frequently the default at registrars and shared hosts. Long enough that half a working day is affected. |
| 86,400 seconds | 24 hours | Still widely set on apex records. A change made on Monday can still be missing for someone on Tuesday. |
The part almost nobody publishes
DNS caches failures, not just successes
If you look up a domain before its record exists, your resolver stores the "no such name" answer and keeps serving it back to you. RFC 2308 defines that negative caching duration as the smaller of the zone SOA MINIMUM field and the SOA record TTL.
The RFC notes the protocol technically allows caching for up to 68 years, recommends resolvers cap it, and says values of one to three hours work well while values exceeding one day "have been found to be problematic".
This is why a domain you just fixed still reports as missing for you and works for everyone else. You are not looking at the internet, you are looking at a cached failure, and there is nothing to do but wait it out or ask a resolver that never saw it. The checker above queries four, which is usually enough to prove the record exists.
Triage in order
My website is down, how do I fix it?
Outages get longer when people debug in parallel instead of in order. Work up the stack, and stop at the first layer that fails, because everything above it is a consequence rather than a cause.
-
Step 1
Confirm it is down for everyone, not just you
Run the check above. If it comes back up from outside your network, the problem is between you and the internet: cached DNS, a captive portal, corporate filtering or a browser cache. Stop looking at the server.
-
Step 2
Read which layer failed first
The result names the layer. A DNS failure is not a server problem, a TLS failure is not an application problem, and a 500 is not a network problem. Every minute spent on the wrong layer is a minute of downtime.
-
Step 3
If DNS failed, go to the registrar before the server
Check the expiry date on the domain, then that the nameservers listed at the registrar match the ones actually serving the zone, then that the A record still exists. An expired domain and a deleted record look identical from outside and neither is fixed by rebooting anything.
-
Step 4
If TCP failed, check the process and then the firewall
Connection refused means the host is up and nothing is listening: the web server has stopped or crashed. A timeout means packets are being dropped silently, which points at a firewall, a security group or a host that is too loaded to accept connections.
-
Step 5
If TLS failed, check the expiry date first
Certificate expiry is the one outage you can predict to the second, and it is still one of the most common. If the date is fine, check that the certificate covers the exact hostname being requested, including or excluding www, and that the intermediate certificate is being sent.
-
Step 6
If HTTP returned 5xx, read the application log
A 500 is an unhandled exception in your code. A 502 means the process behind the proxy is down or crashed. A 504 means it is alive but too slow to answer. The status code tells you which of those three to look at, and the log tells you why.
-
Step 7
If HTTP returned 403 to the checker but 200 in your browser
A firewall or bot rule is matching non-browser clients. The page is fine and the rule is the problem. Worth fixing rather than ignoring, because rules broad enough to block a checker sometimes block search crawlers too.
-
Step 8
Once it is back, find out how long it was gone
The gap between the failure and someone noticing is the part you control. If the answer came from a customer email, the monitoring is what needs fixing next, not the server.
If the failure landed on HTTP, the status code narrows it further. A 502 bad gateway means the process behind the proxy is not answering, a 503 service unavailable is usually overload or a deliberate maintenance mode, and the Cloudflare specific numbers narrow it further still: 521 means the origin refused the connection while 522 means it never answered at all. To see the exact code and the full redirect chain for any URL, use the HTTP status code checker.
Where to look first
Where the cause usually is, by how your site is hosted
The layer tells you what broke. How your site is hosted tells you where to look for it, because each hosting shape fails in its own characteristic way and puts the evidence in a different place.
| Hosting | How it typically goes down | Where the evidence is |
|---|---|---|
| Shared hosting or cPanel | Account suspension for resource limits or an unpaid invoice, a PHP version bump applied by the host, or a neighbour on the same box exhausting resources | The host status page and the account notices in the control panel, before touching any code |
| VPS or dedicated server | A stopped web server, a full disk, an out-of-memory kill, or a firewall rule added during maintenance | systemctl status for the web server, then disk usage, then the system log for OOM kills |
| Managed WordPress | A plugin or core update that fataled, a PHP memory limit, or the host putting the site into maintenance mode mid-update | The host dashboard for a stuck update, then the PHP error log, then disable plugins from the file system |
| Behind Cloudflare or another CDN | The edge is up and the origin is not, which produces a 5xx branded by the CDN rather than by your server | The specific error number tells you the fault: 521 means the origin refused the connection, 522 means it never answered, 525 means the TLS handshake to the origin failed |
| Static hosting or a serverless platform | A failed build deployed as the live version, an expired custom domain certificate, or a spending cap reached mid-month | The most recent deployment log and the billing status, in that order |
Honest comparison
Five ways to check, and what each one is actually good for
Every method here has a real use and a real blind spot. Ours included: this page checks from one node, so it can prove a site is down and it cannot prove a site is down only in one region. Tools that check from a dozen locations answer that better, and several are run by companies we compete with.
| Method | What it does | What it is good for, and where it fails |
|---|---|---|
| This checker | One request from our node, testing all four layers | Names the layer that failed instead of just reporting "down". Queries four independent DNS resolvers, so it separates a propagation problem from a dead domain. It is one vantage point, so it cannot prove a regional outage on its own. |
| Reloading in your browser | One request from your machine, with all your state attached | The fastest thing to try and the least trustworthy answer. Cached DNS, HSTS, session cookies and service workers all make your browser disagree with reality in both directions. |
| curl on the command line | curl -sSv https://example.com -o /dev/null | The most precise view and the only one that scripts cleanly. Shows the DNS answer, the handshake and the status line in one output. Still a single machine on a single network. |
| Downdetector style report sites | Aggregated complaints from other users | Useful for a large consumer service where thousands of people report at once. Useless for your own site, because nobody except you is reporting it. |
| Continuous monitoring | A scheduled check on a fixed interval from several regions | The only method that answers the question while you are asleep. Everything above requires you to already suspect a problem, which means the outage started before you started looking. |
The gap every one of the first four shares is time. They all require you to already suspect a problem, which means the outage began before you started looking, and the minutes between those two moments are the ones your customers spend on a broken page. Working out what that gap costs against a target is what the uptime calculator is for: at 99.9 percent you have 43 minutes and 48 seconds a month in total, and a single outage found by a customer email usually spends most of it.
Asked during outages
Website down questions, answered
How do I check if my website is down?
Request the site from outside your own network rather than reloading it in your browser. Enter the address in the checker at the top of this page and it resolves the domain against four public DNS resolvers, opens a connection, completes the TLS handshake and reads the HTTP status code, then reports which of those four steps failed. Checking from outside matters because your browser caches DNS answers and carries session cookies, both of which hide the real state of the server.
Is my website down or is it just me?
If a checker outside your network reaches the site and you cannot, the problem is on your side. The usual causes are a cached DNS answer that is now wrong, a browser holding an HSTS record that forces HTTPS, a service worker serving a cached copy of the page, or DNS filtering on your corporate or ISP network. If the outside check also fails, the site is genuinely down for everyone.
Why is my website down?
A website fails at one of four layers, and the first one to fail is the cause. DNS fails when the domain no longer resolves, usually because it expired or a record was changed. TCP fails when nothing accepts a connection, meaning the web server stopped or a firewall is blocking. TLS fails when the certificate is expired or wrong for the hostname. HTTP fails when the application returns a 5xx. Identifying the layer first is what stops you debugging the wrong thing.
My website is down, how do I fix it?
Work up the stack in order rather than guessing. Confirm it is down from outside your network, read which layer failed, then go straight to that layer: the registrar and DNS zone for a resolution failure, the web server process and firewall for a refused or timed out connection, the certificate for a handshake failure, and the application log for a 5xx. Restarting the server first is the most common wasted step, because it does nothing for a DNS or certificate problem.
Why is my website down but the server is up?
Because being up is four separate things and only one of them is the server running. A domain that no longer resolves, a certificate that expired overnight, and a firewall rule that quietly started dropping traffic all leave a perfectly healthy server serving nobody. This is exactly why the checker above reports each layer separately instead of a single up or down light.
I fixed my DNS but the site still says it does not exist. Why?
Your resolver cached the failure. DNS caches negative answers as well as positive ones, and RFC 2308 sets that duration from the smaller of the zone SOA MINIMUM field and the SOA record TTL. The RFC recommends resolvers cap it at one to three hours and warns that values over a day cause problems. Until that cached "no such name" expires, the fix is invisible to you while working for everyone whose resolver never saw the failure.
How long does a DNS change take to take effect?
Up to the TTL that was on the old record, not the TTL on the new one. A resolver that fetched the record one second before you changed it keeps the old answer for the full TTL. With the common one hour TTL, that is up to an hour of some visitors reaching the old address and some the new one. The practical move is to lower the TTL a day before a planned migration, not on the day.
Is my website up or down right now?
The check at the top of this page answers that for this moment: it returns the current DNS answers, whether the connection was accepted, whether the certificate is valid and the HTTP status code the server returned. What a one-off check cannot tell you is whether the site was up an hour ago or will be in ten minutes, which is the difference between a status checker and monitoring.
How can I check how long a website has been down?
A one-off checker cannot tell you, because it only sees the current moment. Duration comes from a record of repeated checks over time, which means either continuous monitoring you set up before the outage, or an external source such as a status page, a CDN log or Google Search Console host status. Our guide to reconstructing website downtime history covers what each of those sources can and cannot prove. The short version: the first question after "is it down" is always "since when", and only a record kept at the time can answer it.
What causes a website to go down?
In rough order of how often they actually happen: an application error returning 5xx, a certificate that expired without anyone watching the date, a deploy that failed and shipped a broken build, a resource limit reached on the host, a DNS record or domain that expired, and a firewall or WAF rule added for something else that caught real traffic too. Hardware failure is far down the list on modern hosting.
Does website downtime affect SEO?
Yes, and the status code decides how badly. Google documents that URLs returning 5xx are kept in the index for a while and eventually dropped if the errors persist, and that crawl rate is reduced while the errors continue. URLs returning 4xx are not indexed at all and existing ones are removed. A short 5xx outage is recoverable, a sustained one is not, and a misconfiguration that serves 404 or 410 does more damage faster than an outright outage.
Why does my website work on my phone but not my computer?
Different network, different resolver, different cache. Your phone on mobile data uses the carrier resolver and has never seen your machine cached DNS answer, your HSTS record or your service worker. Two devices disagreeing about a site is almost always a client-side cache difference rather than the server behaving differently for each of them.
How often should I check my website?
Often enough that the check interval is small compared to the downtime you are willing to accept. A five minute interval means an outage can run for five minutes before the first failed check, which on a 99.9 percent monthly target already spends more than the entire budget in a single detection. Thirty to sixty second intervals are the practical range for anything that makes money.
Does this checker store the sites I check?
No. The check runs when you press the button, the result is returned to your browser and nothing about it is written down. There is no account and no history, which is also the reason it cannot tell you anything about yesterday.
Keep going
Related checks and reading
HTTP status code checker
The exact code and every redirect hop for up to six URLs, plus what each code means for Google indexing.
SSL certificate checker
Expiry date, chain, hostnames and the shrinking certificate lifetime schedule that changes how often you renew.
Uptime calculator
What each uptime percentage allows per day, week, month and year, in both directions.
Multi-location monitoring
Checking from six regions is what separates a regional routing problem from a real outage.
DNS monitoring
Watching the records themselves, so a changed or deleted answer alerts before anyone notices the site is gone.
Website downtime history
The follow-up question. Which sources can reconstruct how long a site was down after the fact, and what each one actually proves.
Best uptime monitoring tools
Thirteen tools compared on check interval, regions, alerting and price, including where each one wins.
You are on this page because something already went wrong
A checker tells you the site is down after you have started worrying. Uptimehub requests it every 30 seconds from six regions and tells you first, watching DNS, the certificate expiry date, the port and the status code at the same time. From $9 a month, priced per monitor and never per seat.