Troubleshooting a down website

Work down the stack, in order. Each step tells you whether to keep going down or stop.

Step 1: Is it you or everyone?

curl -I https://example.com            # from your machine
# from an external vantage point (use the panel's tools or a third-party checker)

Try a different network (mobile data). If it is only you, the problem is local: your DNS cache, your network, or your browser. If everyone, continue.

Step 2: DNS

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

No answer? The DNS record is missing or the zone moved. The wrong IP? A record change has not propagated. See Troubleshooting DNS.

Step 3: Reachability and the web server

ping -c 4 <ip>
curl -I -H 'Host: example.com' http://<ip>/     # does the server answer at all?

• No response to ping — the host is down or firewalled. Check the panel's status; use the console.

• Connection refused — something is listening that should not be, or a firewall is rejecting. Also check fail2ban has not banned you.

• Answers locally, not publicly — the web server is up; DNS or the firewall is the issue.

Step 4: The web server

systemctl status nginx --no-pager
nginx -t                          # config valid?
tail -50 /var/log/nginx/error.log

A bad config or a crashed server shows here immediately.

Step 5: The application

systemctl status myapp --no-pager
journalctl -u myapp -n 100 --no-pager

Crash-loops, missing environment variables, and unhandled exceptions all surface here.

Step 6: The database

systemctl status postgresql --no-pager     # or mysql
psql "postgresql://user:pw@host/db" -c 'select 1;'

A site that loads but shows errors often has a database that is down, refusing connections, or out of disk.

Step 7: Resources

df -h            # a FULL DISK breaks almost everything
free -h          # out of memory?
uptime           # load average vs core count

A full disk is one of the most common causes of a site that "was fine yesterday". See Bandwidth vs CPU bottlenecks.

Step 8: Recent changes

What changed last? A deploy, a config edit, an update, a certificate renewal, a DNS change? Reverting the last change is frequently the fastest fix. This is precisely why you took a snapshot.

Get help faster

When opening a ticket, include: the URL, the exact error, what you have already checked, and roughly when it started. That turns a long back-and-forth into a fix.

Related reading

• HTTP error codes and what to do about them

• Reading your server logs