Is it down, or is it me? Debugging a site that won't load, one layer at a time

upordown.online — Sun, 25 Oct 2026 21:30:26 +0000

"The site is down" is one of the least useful bug reports there is. Down for whom? Down how? A page that never loads, a certificate warning and a 502 Bad Gateway are three completely different problems with three different owners.

The fastest way to stop guessing is to walk the same path your browser walks, one layer at a time. Every request to https://example.com goes through roughly five steps, and each one fails in its own recognizable way.

1. DNS: can the name be turned into an address?

Before anything else, the name has to resolve.

dig +short example.com A
dig +short example.com AAAA

No answer, NXDOMAIN or SERVFAIL means you never got as far as the server. Compare against a public resolver to see whether it's your resolver or the domain itself:

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8

If public resolvers answer and yours doesn't, the problem is local (router, ISP resolver, a stale cache). If nobody can resolve it, the domain's DNS is broken or the domain has expired. A useful sanity check is whether other names resolve for you at all: if sites fail by name but you can still reach an IP like 1.1.1.1, your DNS is the thing that broke, not "the internet".

2. TCP: does anything answer on the port?

An address doesn't mean a listening server.

nc -vz -w 6 example.com 443

"Connection refused" means a machine answered but nothing is listening on that port, which is often a crashed service or a misconfigured load balancer. A timeout means packets disappear somewhere: a firewall, a routing problem, or a host that is simply gone.

3. TLS: does the secure handshake complete?

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

Look at notAfter. Expired certificates still take down real sites, usually on a weekend. Also check the subject actually covers the hostname you asked for. One sneaky client-side cause: if your device clock is far off, a perfectly valid certificate looks expired or not yet valid, and browsers show NET::ERR_CERT_DATE_INVALID.

4. HTTP: what did the server actually say?

Now the request itself. curl can print a timing breakdown that maps neatly onto the layers above:

curl -s -o /dev/null -L --max-redirs 4 \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s code=%{http_code}\n' \
  https://example.com

How to read the status code is where most "is it down?" arguments come from:

200, 301/302: up.
403 or 429: the server is reachable; it just doesn't like your client. Large sites routinely block scripts and data-center IPs. That's not an outage.
503: the server is alive but says it can't serve right now: overload or maintenance. Degraded, not gone.
500, 502, 504: something behind the front door is failing. This is the classic real outage.

5. Time: is it slow enough to count as broken?

A page that answers after 25 seconds is "down" to every human who tried it. Set explicit limits instead of waiting forever:

curl -s -o /dev/null --connect-timeout 6 --max-time 10 -w '%{http_code} %{time_starttransfer}\n' https://example.com

Time to first byte is the honest number here, because it includes DNS, connection and handshake, the parts users actually wait on.

Don't trust a single failure

Networks drop packets. A single failed request is a data point, not an incident. Retry once after a couple of seconds before you page anyone or post "X is down" in the team channel. Most transient blips vanish on the second try; real outages don't.

Then change your vantage point

Everything above tells you what happens from your machine. To answer "is it me?", you need a second opinion from somewhere else:

Run the same check from a server in another region (a cheap VPS, a CI runner, a cloud shell).
Try mobile data instead of Wi-Fi. That swaps your ISP, your router and your DNS in one move.
Check the service's official status page, but treat it as the provider's statement, not as a measurement. They are often updated after users notice.

If it works from elsewhere and fails for you, start with your own DNS and network. If it fails everywhere, it's them, and the useful thing you can do is report which layer failed: "TLS handshake fails, cert expired at 00:00 UTC" gets fixed much faster than "site down".

A shortcut when you're in a hurry

I help run upordown.online, a free checker that automates this exact sequence: DNS lookup, connection, TLS verification and the first byte of the homepage with fixed timeouts and a repeat check before anything is called an outage, then shows that next to tests from home and mobile connections in other countries. The page linked above documents every rule it uses, which is handy even if you only want a checklist to copy into your own monitoring.

But the real takeaway is the method: name the layer, then change the vantage point. Once you do that, "is it down or is it me?" usually answers itself in under a minute.

DEV Community: upordown.online