Troubleshoot a website that is down

When a website stops working, it is tempting to change several things at once. Resist that. Work through the layers in order, from the name in DNS, through the network and firewall, to the web server and the application. Each check rules out a part of the stack, so you find the real fault instead of guessing.

Before you begin

SSH access to your VPS as a user with sudo rights, such as alex.
Your domain (we use example.com) and the server's public IP address (we use 203.0.113.10).
A site served by nginx on Ubuntu 24.04 LTS. The same ideas apply to other web servers.

Step 1: Check that DNS points at your server

Start from the outside. Visitors find your site by looking up the domain name. If the name points at the wrong address, the rest of your server can be perfect and still invisible. Install the DNS tools, then ask for the address the world sees:

sudo apt update
sudo apt install -y dnsutils
dig +short example.com

203.0.113.10

If the answer is empty or a different address, the fault is at your DNS provider, not on the server. Fix the record there, and remember that changes can take time to spread.

Step 2: Check that the server is reachable

Ping sends small test packets to the server. A reply means the machine is up and the network path works. Many servers block ping, so a failure here is a hint, not proof.

ping -c 3 203.0.113.10

3 packets transmitted, 3 received, 0% packet loss

If there is no reply at all, check the server status in your control panel. If SSH also fails, see the guide on recovering access with the console.

Step 3: Check that the web ports are open

Next, confirm that something is listening on ports 80 (HTTP) and 443 (HTTPS), and that the firewall allows them. ss -tlnp lists listening TCP ports and the program that owns each one.

sudo ss -tlnp | grep -E ':(80|443)\s'
sudo ufw status

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812,fd=6))

Status: active
To                         Action      From
--                         ------      ----
Nginx Full                 ALLOW       Anywhere

If nothing listens on 443, the web server is not running. If ufw is active and the ports are not allowed, add the web rule with sudo ufw allow 'Nginx Full' and check again.

Step 4: Check the web server service

Ask systemd whether nginx is running, and test its configuration file for syntax errors. A broken config is one of the most common causes of an outage after an edit.

sudo systemctl status nginx --no-pager
sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If the test fails, it prints the file and line number. Fix that line, then restart with sudo systemctl restart nginx.

Step 5: Test the site from the server itself

Request the site locally, skipping DNS and the firewall. If this works but the public check failed, the problem lies in the network layer. If this fails too, the problem is in the web server or the app.

curl -I -H "Host: example.com" http://127.0.0.1/

HTTP/1.1 200 OK

A 502 Bad Gateway usually means nginx is running but the app behind it is not. A 500 points at the application's own code.

Step 6: Read the logs

Logs say what went wrong in plain words. Read the last lines of the nginx error log, then the journal for the app's service if it has one. Replace hello with your service name.

sudo tail -n 50 /var/log/nginx/error.log
journalctl -u hello.service -n 50 --no-pager

Step 7: Check disk space and certificates

A full disk stops logs, uploads, and sometimes the whole web server. Also check that the certificate is still valid.

df -h /
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   18G   22G  46% /

Tip: Write down what each step showed before you change anything. If you fix one thing and the site returns, you know which layer was at fault, and you can record it for next time.

Careful: Do not restart services or reboot in a loop. Each restart clears some evidence from the logs. Read first, then restart once.

Troubleshooting

Only some visitors see the problem. Check the DNS answer from your own machine, and remember that some caches keep old records for a while.
Port 443 works, but the browser shows a certificate warning. The certificate has expired or does not match the domain. Renew or re-issue it, then reload nginx.
Everything looks fine, but the site is slow. Check load with uptime and memory with free -h. A server out of memory can appear to be "down".
Your own IP is blocked. If you locked yourself out with the firewall, use the provider's console to restore access as described in the rescue console guide.

Next steps

Set up uptime checks so you learn about the next outage before your visitors do. Then keep this checklist in a note, so the first five minutes of any incident are calm and ordered.