Is my website down? How to find out what broke

First, rule yourself out - it takes thirty seconds

Before you touch anything on the server, find out whether the problem is between you and the internet rather than at the site:

• Open the site on your phone with Wi-Fi switched off, over cell data. That is a completely different route to the same server. If it loads there, your site is up and the problem is your own network, your router, or your home DNS.
• Try a private window, or a different browser. That rules out a cached redirect, a stale login, or a browser extension.
• Try a different page on the same site. One broken page is a different problem from a site that will not answer at all.

This catches a surprising share of "my site is down" panics, and it costs nothing.

Then work down the four layers, in order

A website is a stack of things that each have to work, and a failure near the bottom makes everything above it look broken too. Check them in this order and stop at the first one that fails - that is your actual problem, and everything after it is noise.

1. Does the name still turn into an address? (DNS)

Before anything can connect to your site, your domain has to resolve to an IP address. If it does not, nothing above this matters.

This layer breaks in dull, common ways: a domain that quietly expired, a nameserver change that has not finished spreading, a DNS record someone edited last week, or a registrar hold that pulled the domain out of DNS entirely. It is also the layer most likely to look like a server problem when it is not.

Check it with the DNS record lookup. If your name does not resolve, stop here - fixing your web server will not help.

2. Does anything answer at that address? (the server)

The name resolves, so now something has to accept a connection at that address. If nothing does, the server or whatever sits in front of it is switched off, still starting up, out of memory, or dropping the request at a firewall.

This is the layer people mean when they say "the site is down", and it is the one where you genuinely do have to go and look at the machine.

3. Does the secure connection work? (the certificate)

If something answers but the connection fails before any page appears, that is good news of a sort: your server is running. The problem is its certificate or HTTPS setup - an expired certificate, a renewal that failed quietly weeks ago, a certificate for the wrong name, or a missing intermediate.

This is a much smaller repair than a dead server, and it is worth knowing which one you have before you start. The padlock and SSL/TLS check tells you what the certificate says and when it expires. If the renewal itself is failing, the Let's Encrypt renewal check looks at the specific things that stop a certificate from issuing.

4. Does the server actually return your site? (the HTTP status)

The last layer is the one that separates "answering" from "working". A server can accept your connection, complete the encryption, and then hand back an error page instead of your site.

That is what a status code tells you, and the security headers checker will show you the real one - along with which of the layers above broke, if it got that far.

The trap: "but it pings fine"

This is the part worth reading twice, because it is where most people get a confidently wrong answer.

If your site sits behind Cloudflare, Shopify, Squarespace, Wix or any similar service - and most small business sites now do - then you are not pinging your site. You are pinging their edge servers, which are enormous, geographically spread, and essentially never down. They will answer cheerfully while your actual server, sitting behind them, is dead.

That is exactly what a Cloudflare Error 521 page means: the edge is fine, your origin is not. A ping cannot see that difference. Neither can any tool that only asks "is this host alive". The only thing that can is a real request that comes back with a real status code.

It fails in the other direction too. Plenty of perfectly healthy servers are configured to ignore ping entirely, so "no reply" is not evidence of anything either. Both errors are live, and the reassuring one - "your site is up" when it is not - is the more dangerous of the two.

What the common error codes actually mean

• 521, 522, 523 (Cloudflare). The edge is up and your origin server is not answering it. Your problem is layer 2 above, on your own machine.
• 502 Bad Gateway. Something in front reached your application and got nonsense back - very often the application crashed and the web server in front of it is still running.
• 503 Service Unavailable. The server is deliberately saying "not right now" - overloaded, restarting, or in maintenance mode.
• 500 Internal Server Error. Your application ran and threw an error. The server is fine; your code or its database is not.
• 403 Forbidden. Something is refusing on purpose - permissions, a firewall rule, or a security plugin that has decided you are a threat.
• 404 Not Found. The server is working perfectly and that page does not exist. This is not a site being down.

Notice that every one of these means your server answered. That is a much better position to be in than silence, and it points at a much smaller repair.

Why two "is it down?" sites disagree with each other

Because they are standing in different places. A site checked from Toronto, from Frankfurt and from Singapore can genuinely be up in one and down in another - a DNS change that has not spread, a regional network fault, or an edge location having a bad day.

The same limit applies to us, and we would rather say so: our checks run from one place, in Canada. If everything here looks healthy but the site still will not load for you, that gap is the answer - try it on cell data, and ask someone in another city.

If it is not your site

If you are just trying to buy something and the shop will not load, the same first step applies: try it on cell data. After that, be careful what you do next. "This site is down, use this other link" is a common setup for a look-alike shop, and a search for a broken retailer is a good moment to end up somewhere you did not mean to go. If a link arrives while you are already frustrated, check it before you click.

The short version

Try your phone on cell data first. Then check, in order: does the name resolve, does anything answer, does the certificate work, and what does the server actually return. Stop at the first failure. And do not trust a ping - behind a CDN it will tell you everything is fine while your site is down. Check what your server really returns.