Website Down? A Step-by-Step Troubleshooting Checklist

When a website is down, first confirm it is down for everyone and not just you. Then work from the outside in: DNS, the connection, the TLS certificate, the CDN or proxy, the web server and finally the application and its dependencies. The error you see usually tells you which layer to start with, and each step below has a quick test that rules it in or out.

Keep notes as you go: what you checked, at what time, and what you saw. They make the fix faster to hand over and the postmortem easier to write.

Step 1: Is it down for everyone, or just you?

Paste the address into the Is it down? checker. It requests the page from Stockholm, Sweden, follows up to five redirects and counts anything below HTTP 500 as up. Then try the site on your phone with Wi-Fi turned off.

If it works from outside but not for you, the problem is close to you: a VPN, a hosts file entry, your router’s DNS cache, a browser extension, or a firewall that blocked your IP address after too many failed logins. Try a private window and another network before you touch the server.

Read the error message

The exact error points at the layer that failed. Note it down before you start changing things.

What you see	Likely layer	Start at
DNS_PROBE_FINISHED_NXDOMAIN, “server IP address could not be found”	DNS or domain	Step 2
ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT	Network or server	Step 3
“Your connection is not private”, NET::ERR_CERT_DATE_INVALID	TLS certificate	Step 4
Cloudflare 521, 522, 525 or 526, or a CDN error page	CDN to origin	Step 5
500, 502, 503 or 504	Web server or application	Step 6
A page that loads but is blank or shows an error	Application or dependency	Step 7

Step 2: Check DNS and the domain

If the name doesn’t resolve, nothing else matters. Ask DNS what it answers for your domain and compare it with your server’s address:

dig +short example.com A
dig +short www.example.com
dig +short example.com NS

• No answer at all: check whether the domain registration has expired with the domain expiry checker. An expired domain often loses its nameservers or points at the registrar’s parking page.
• The wrong address: someone changed a record, or the nameservers moved to a provider without your records. Compare the answer with what you expect using the DNS lookup tool.
• Right for some, wrong for others: a recent change is still spreading. Resolvers keep the old answer until its TTL runs out, which is DNS propagation.

Our guide to DNS_PROBE_FINISHED_NXDOMAIN goes through the DNS causes one by one.

Step 3: Can you reach the server?

With the right address, test whether the server accepts connections on the web ports:

nc -vz example.com 443
curl -sv -o /dev/null https://example.com/

• Connection refused: the machine answers, but nothing listens on the port. The web server has stopped or crashed. Start it and read its log to find out why.
• Timed out: packets go nowhere. The server is off, a firewall or security group drops the traffic, or the network in between has a fault. Look at your hosting provider’s status page and console.

Don’t rely on ping alone. Many hosts block ICMP, so a server can fail ping and serve the website fine, or answer ping while the web server is down.

Step 4: Check the TLS certificate

A certificate problem takes the site down for everyone at once, with a full-page browser warning, while the server itself is fine. Run the host through the SSL checker, or look from the command line:

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

The usual causes are an expired certificate after a failed automatic renewal, a certificate for another name, or a missing intermediate certificate. SSL certificate errors explained maps each browser warning to its fix.

Step 5: Rule out the CDN or proxy

If a CDN or reverse proxy sits in front of the site, an error page may come from the proxy, not your server. Cloudflare’s 52x codes say exactly where it broke:

• 521: the origin server refused the connection.
• 522: the connection to the origin timed out.
• 525: the TLS handshake with the origin failed.
• 526: the origin’s certificate isn’t valid.

To test the origin without the CDN, send the request straight to its IP address while keeping the host name. Replace 203.0.113.10 with your origin’s address:

curl -sv -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/

If the origin answers fine, look at the CDN: its status page, firewall rules you changed recently, and whether it still has the origin’s right address. If the origin fails too, move on to the server.

Step 6: Check the web server and the application

A 5xx status code means the request reached your stack and something there failed. The code narrows it down:

• 500: the application threw an error. See 500 Internal Server Error.
• 502: the web server couldn’t get a valid answer from the application process behind it, often because that process crashed. See 502 Bad Gateway.
• 503: the service is overloaded or in maintenance mode. See 503 Service Unavailable.
• 504: the application took too long to answer. See 504 Gateway Timeout.

Every code has its own page in the HTTP status code reference. On the server, three checks find most causes:

df -h                                  # a full disk stops databases, logs and uploads
free -m                                # out of memory kills processes
tail -n 50 /var/log/nginx/error.log    # or your web server and app logs

Then ask what changed. A deploy, a plugin update, a configuration edit or an expired API key in the last hour is the most likely cause, and rolling it back is often faster than debugging it live.

Step 7: Check the dependencies

Your site can be healthy while something it needs isn’t. A database that is out of connections, a cache server that stopped, or a payment, email or login provider having an outage all break pages that otherwise load. Check your providers’ status pages, and look up the big ones on Is it down?, which tracks well-known services and their recent outages.

When the site is up but broken

Some failures answer 200: an empty product list, a checkout button that does nothing, an error message inside a normal page. A status code won’t catch these. Check that the page contains what it should, and walk through the journey that matters, such as logging in or paying, the way a customer would.

While you fix it: tell people

Post a short update as soon as you know there is a problem, even if all you can say is that you are investigating, and promise when the next update comes. The status update generator writes one for each stage, and the incident communication plan covers who says what and where.

Make the next outage shorter

The slowest part of most outages is finding out about them. With external monitoring, you hear about the problem from an alert instead of a customer, and you start with evidence instead of guesses. Here is what Uptimecheck gives you:

• Checks every minute from Stockholm, Sweden, with each failure confirmed by a second check about 10 seconds later before you are alerted. See uptime monitoring.
• Evidence in the incident: the address DNS resolved to, redirects, the certificate, headers and the start of the response, plus a screenshot when the server answered or a traceroute when it didn’t. See how incidents and evidence work.
• Response times split into phases: DNS, connect, TLS, server and download, so a slow layer stands out before it fails.
• Reminders before expiry for certificates and domains, and alerts when DNS records change.
• Keyword checks and flows that catch a page that answers 200 but is broken. See flow monitoring.

If a monitor says down while the site works for you, why a monitor is down when your site works explains how to read the difference.

Find out before your customers do. Try Uptimecheck free for 14 days, no credit card required.