"The site is down" can mean a dozen different things. The fastest way to fix it is to stop guessing and test each layer of the stack in order, from the name all the way to the response. Each layer you clear rules out a whole category of causes.
Layer 1: Does the name resolve? (DNS)
If DNS is broken, nothing else can work. Run a DNS lookup on the hostname and confirm it returns an A (and/or AAAA) record pointing at the IP you expect.
- No record → the record was deleted or the domain isn't delegated. Check the nameserver trace.
- Wrong IP → you're pointing at an old server; fix the record.
- Right IP but only for some people → a propagation lag. Confirm with a propagation check.
Layer 2: Is the server reachable? (Connectivity)
The name resolves to an IP, but is anything answering there? Use the ping / reachability tool against the host on port 443 (and 80).
- Reachable, fast → the server is up; move to Layer 3.
- 100% loss → the host is down, the port is closed, or a firewall is dropping traffic. This is an infrastructure problem, not DNS.
- Flaky (partial loss) → an overloaded server or a saturated link.
Layer 3: Is TLS valid? (SSL)
A reachable server can still refuse to load in browsers if its certificate is broken. Run the SSL / TLS certificate checker and look for:
- An expired certificate (the classic "was working yesterday").
- A hostname mismatch (cert doesn't cover the name you used).
- A broken chain (a missing intermediate, works in some clients, fails in others).
"Not secure" right after a DNS or host move almost always lands here.
Layer 4: What does the server actually say? (HTTP)
DNS, reachability and TLS are fine, but the page still fails. Now read the server's own answer with the HTTP response header viewer:
- 200 → the server is serving; the problem is in the app or the browser/CDN cache.
- 301/302 chain → a redirect loop or an unnecessary extra hop.
- 502 / 503 / 504 → the origin or a proxy is failing behind the front door.
The order saves you
Name → reachability → TLS → response. Each cleared layer eliminates a class of causes, so by the time you reach the real failure you already know it isn't DNS, isn't the network, and so on. That's the difference between a five-minute fix and an afternoon.
FAQ
It works for me but not for others (or vice-versa). Why?
That's the signature of DNS propagation or a per-network issue. Run a propagation check; if answers differ by region, it's caching. If they agree, it's local to whoever can't reach it.
The site loads but shows "Not secure." Is that an outage?
To most visitors, effectively yes, browsers block or warn. Jump to Layer 3 and check the certificate's expiry, hostname coverage and chain.
Everything checks out but the page still errors. Now what?
You've cleared DNS, network, and TLS, so it's the application or a CDN/cache. Read the HTTP status and headers (Layer 4) for the specific error the origin is returning.