When a site stops loading, the cause is usually one of four things: the app, the server, DNS, or the domain itself. Work through these checks in order and you will know which one it is in a few minutes.
1. Is it only you?
Before anything else, rule out your own connection. Load the site on your phone with mobile data, and check it from an outside service like downforeveryoneorjustme.com. If it loads elsewhere, the problem is your network or your local DNS cache, not the server.
2. Is the server reachable?
$ ping -c 3 203.0.113.10 $ ping6 -c 3 2001:db8:1:2::1
If the server answers, it is running and on the network, so the problem is above that level: skip to step 4.
If nothing answers, log in to your client area and look at the service page. The status there tells you whether the server is running or stopped. Start it if it is stopped, and use Console under Service management to see the screen directly, which works even when the network inside the server is broken.
3. Is SSH working?
$ ssh [email protected]
If ping works but SSH does not, the server is up but something on it is wrong: a firewall rule, a stopped SSH service, or a full disk. Our SSH lockout guide covers the recovery through the console.
4. Is the web server running?
Once you are logged in:
$ systemctl status nginx $ ss -tlnp | grep -E ':(80|443)'
systemctl status shows whether the service is running and prints the last log lines if it failed. ss shows what is listening on the web ports. If nothing is listening there, the web server is not running.
$ sudo nginx -t $ sudo systemctl restart nginx
Run the config test first. A service that refuses to start after a config change is the most common cause, and nginx -t names the broken line.
5. Is the disk full?
A full disk stops web servers, databases, and logging all at once, and the errors it produces rarely mention disk space.
$ df -hIf the root filesystem is at 100%, that is the problem. Our guide on freeing disk space walks through it.
6. Is DNS still correct?
$ dig example.com A +short $ dig example.com AAAA +short
The answers must match your server's addresses. If they do not, either the records were changed, or the domain expired and the registrar replaced its DNS. Check the domain's expiry date at your registrar while you are there, because an expired domain looks exactly like a dead server from the outside.
7. Is the certificate expired?
If the site loads over HTTP but browsers refuse HTTPS, check the certificate:
$ sudo certbot certificates $ sudo certbot renew
Look at the logs before you restart anything
Restarting a service clears the evidence. Check journalctl -u nginx -n 50 or journalctl -xe first. The cause usually appears in the log shortly before the symptom, so scroll back a minute or two from when the site stopped answering.
What to send us if you still need help
If you open a ticket, include: what the site does now (error message, timeout, wrong page), when it last worked, what changed before that, and the output of the commands above that failed. That turns a long conversation into one reply.
Quick reference
| Symptom | Check | Likely cause |
|---|---|---|
| Nothing loads anywhere | ping, service page | Server stopped or network |
| Ping works, SSH does not | Console in client area | Firewall, sshd, or full disk |
| SSH works, site does not | systemctl status nginx | Service stopped or bad config |
| Everything looks fine | dig, registrar | DNS changed or domain expired |
| HTTPS fails only | certbot certificates | Certificate expired |
Where to go next
Once the site is back, set up monitoring so you hear about the next outage before your visitors do. Our guide on self-hosting Uptime Kuma covers a free way to do it.