My Website Is Down - A Step-by-Step Checklist

If your website is down, work through it in the order a request travels: is it down for everyone, does the domain resolve, can you reach the server, is the TLS certificate valid, is the CDN or proxy healthy, is the web server running, does the application respond, is the database up, and what changed recently. Each step below takes a minute or less and points you to the layer that failed. Replace example.com with your domain throughout.

1. Confirm it is really down, and for whom

Before touching anything, rule out a problem on your side.

• Open the site on your phone using mobile data, not your Wi-Fi.
• Try a private browser window to skip cached redirects and cookies.
• Use an external check such as the is-it-down tool, which requests the URL from outside your network.

curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

Write down what you see: a status code, a timeout, a certificate warning or "could not resolve host". Each points to a different step below.

2. DNS: does the name resolve to the right place?

dig +short example.com A
dig +short www.example.com
dig +short example.com NS
dig @1.1.1.1 +short example.com A
dig @8.8.8.8 +short example.com A

What to look for:

• No answer at all – the record is missing, the nameservers are wrong, or the domain has expired.
• An unexpected IP – someone changed the record, or you migrated hosts and a record still points to the old server.
• Different answers from different resolvers – a recent change is still propagating, bounded by the record's TTL.

To check the full delegation from the root down, and catch nameserver mismatches at the registrar:

dig +trace example.com
whois example.com | grep -i -E "expir|status"

An expired domain, or a clientHold / serverHold status, stops resolution entirely. Renew it at the registrar first; nothing else on this list matters until it resolves.

3. Network: can you reach the server at all?

nc -vz example.com 443
nc -vz example.com 80

• Connection refused – the host is reachable, but nothing listens on that port. The web server is stopped or bound to another port.
• Timeout – a firewall, security group or the host itself is dropping traffic, or the server is off.

If you have SSH access, try logging in. If SSH also times out, the machine or its network is down; check your hosting provider's control panel and status page.

4. TLS certificate: has it expired or does it match?

Certificate problems show up as browser warnings rather than error codes, and they are one of the most common causes of "the site is down" reports.

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

Check:

• notAfter is in the future. If it has passed, the certificate expired; renew it (for example sudo certbot renew, then reload the web server) and find out why automatic renewal failed.
• The subject or SANs cover the hostname you are visiting, including www.
• The chain is complete. If curl https://example.com/ fails with a verification error but browsers work on some devices, the server may be missing an intermediate certificate.

curl -sSv https://example.com/ -o /dev/null 2>&1 | grep -i -E "expire|subject|issuer|verify|SSL"

5. CDN or proxy: is the edge the problem, or the origin?

If you use a CDN or proxy such as Cloudflare, the error page usually tells you which side failed. Codes like Cloudflare's 521 (origin refused connection), 522 (connection timed out) and 525/526 (TLS problems with the origin) are non-standard codes describing the link between the edge and your server.

Test the origin directly, bypassing the CDN, while keeping the correct hostname:

curl -sS -I --resolve example.com:443:203.0.113.10 https://example.com/

Replace 203.0.113.10 with your origin server's IP. If the origin works directly but not through the CDN, look at the CDN's settings: TLS mode, firewall rules, origin IP, and whether your server's firewall allows the CDN's IP ranges.

6. Web server: is it running and is the config valid?

sudo systemctl status nginx        # or apache2 / httpd / caddy
sudo nginx -t                      # or: sudo apachectl configtest
sudo ss -ltnp | grep -E ":80|:443"
sudo tail -n 50 /var/log/nginx/error.log

A failed config test after an edit is a frequent cause of a web server that will not start after a reload or reboot. Fix the reported line, test again, then sudo systemctl restart nginx.

Also check the basics that stop everything:

df -h      # a full disk breaks logging, sessions, uploads and databases
free -m    # memory exhaustion leads to killed processes
uptime     # load average far above the CPU count means the box is overloaded

7. Application: what status code and what error?

If the web server is up but you get a 5xx, the status code tells you where to look:

• 500 – the application threw an error. See HTTP 500 Internal Server Error.
• 502 – the proxy could not get a valid response from the app; it is often stopped or crashing. See 502 Bad Gateway.
• 503 – overloaded, rate limited or in maintenance mode. See 503 Service Unavailable.
• 504 – the app is too slow to answer. See 504 Gateway Timeout.

sudo systemctl status myapp
sudo journalctl -u myapp --since "30 minutes ago" | tail -n 100
docker ps -a                       # containers that exited or keep restarting
docker logs --tail 100 my-app

8. Database: is it up and accepting connections?

Many "site down" incidents are database incidents with a web front end.

sudo systemctl status postgresql   # or mysql / mariadb
pg_isready -h localhost -p 5432
mysqladmin -u root -p ping

Look for: the service not running, "too many connections" errors, a full disk on the database volume, long-running locks from a migration, or a managed database provider's own incident. If you use a hosted database, check the provider's status page.

9. Deploys and changes: what changed?

If nothing above is obviously broken, ask what changed in the last few hours. Outages often follow a change.

git log --since="6 hours ago" --oneline
sudo journalctl --since "6 hours ago" | grep -i -E "upgrade|install|restart" | head

Consider: a code deploy, a config change, a DNS edit, a package update, an expired API key or credential, a plan downgrade or a billing failure at the host. If a deploy lines up with the start of the outage, roll back first and investigate after.

10. Communicate and recover

• Post a short note on your status page as soon as you confirm the outage.
• Fix, verify from outside your network with the same curl command from step 1, then post a resolution update.
• Write down the timeline and the root cause while it is fresh.

Know before your customers do

This checklist is faster when you already know when the outage started and what the error was. An uptime monitor gives you both. PingRobot checks your site every 5 minutes on Free or every minute on Pro, re-checks failures from a second region to avoid false alarms, and alerts you by email, so you can start at step 2 instead of step 1. For the basics, see what is uptime monitoring.

Start monitoring free — 10 monitors, no credit card.