Your site is live on a VPS. What to check next: a 10-point checklist

The site opens in the browser, the domain works, the padlock is there. It feels done. But a VPS rarely breaks on launch day — it breaks a month later: the disk fills up, the certificate expires, someone finds an open database.

Here are ten things worth checking once right after launch, and then every now and then. Each comes with a command you can run on the server over SSH and what to do with the result. Every command only reads: nothing gets changed or installed.

The commands are for Ubuntu and Debian, the most common systems on a VPS. Most of them work the same elsewhere.

1. Free disk space

When the disk is full, everything stops at once: the database can't write, the site returns errors, sometimes even SSH login fails. Usually the space goes to logs, old Docker images and backups piling up on the same disk.

df -h

Look at the Use% column for the / row. Above 80% — time to look into it; above 90% — urgent.

There is a second way to get “disk full” that few people know about: running out of inodes. An inode is a slot for a file, and every file takes one, even an empty one. If an app creates millions of tiny files (cache, sessions), there is still space, but no new files can be created.

df -i

If you use Docker, see how much it takes:

docker system df

2. Backups

Ask yourself three questions:

1. Are backups made at all? Not “the host probably does something”, but you know where they are and how often.
2. Are they stored somewhere other than this server? A backup on the same disk is gone together with the server.
3. Have you ever restored from one? A backup nobody has tried to restore is a hope, not a backup.

If the database runs in Docker, check that the backup includes the volume with the data, not just the site code. You already have the code in git. Your users' data — you don't.

3. Open ports

Every port open to the internet is a door into the server. Only 80 and 443 (the site) and the SSH port should face outside. The database, Redis, an admin panel — should not.

sudo ss -tlnp

Look at the Local Address column:

• 127.0.0.1:5432 or [::1]:5432 — only the server itself can reach the port. Good.
• 0.0.0.0:5432 or *:5432 — the port is open to the whole internet. Bad for a database.

The Docker trap. If you enabled the ufw firewall and closed a port in it, but the service runs in Docker with ports: "5432:5432", the port is still open. Docker writes its own rules that bypass ufw. To see what Docker has published:

docker ps --format '{{.Names}}  {{.Ports}}'

If you see 0.0.0.0:5432->5432/tcp and the port is not needed from outside, write 127.0.0.1:5432:5432 instead of 5432:5432 in docker-compose.yml.

4. Is your .env or .git publicly readable

This is the most painful leak: .env holds the database password and API keys, and the site serves it to anyone who types the address. Bots try these addresses on every site on the internet around the clock.

Check from your own computer:

curl -s -o /dev/null -w "%{http_code}\n" https://your-site.com/.env
curl -s -o /dev/null -w "%{http_code}\n" https://your-site.com/.git/config

404 or 403 — good. 200 — the file is open to everyone. Block access in the web server config and change every password and key in that file: assume they have already been read.

5. SSH login

If the server accepts password logins, someone is guessing the password. That is not paranoia — see how many failed attempts there were in the last day:

sudo journalctl -u ssh --since "24 hours ago" | grep -c "Failed password"

On a new server with port 22 open, it is usually hundreds or thousands. Check the login settings:

sudo sshd -T | grep -E "passwordauthentication|permitrootlogin"

Key-only login (passwordauthentication no) is best. If you keep passwords, make them long and random, and protect against guessing with fail2ban: it blocks an address after a few failed attempts.

6. Security updates

Holes in the system are found all the time, and updates close them. A server that hasn't been updated in six months is usually vulnerable.

apt list --upgradable 2>/dev/null | grep -i security

One more thing: is the server waiting for a reboot? After a kernel update, the new version only takes effect after a reboot:

ls /var/run/reboot-required 2>/dev/null && echo "reboot needed"

To stop having to remember this, turn on automatic security updates — the unattended-upgrades package.

7. The HTTPS certificate

Let's Encrypt certificates live for 90 days and renew themselves. “Themselves” — as long as renewal works. It breaks quietly: you changed the web server config, moved to another port, closed port 80 in the firewall. You find out when the browser starts showing your visitors a red warning page.

How long until it expires:

echo | openssl s_client -connect your-site.com:443 -servername your-site.com 2>/dev/null \
  | openssl x509 -noout -enddate

If certbot issues your certificate, test the renewal without actually issuing one:

sudo certbot renew --dry-run

8. Domain expiry

A domain expires once a year or less often — which is exactly why people forget about it. By then, the card used for auto-renewal has expired too. A few weeks after expiry, someone else may grab the domain.

Check with your registrar that auto-renewal is on and the card is valid. You can also see the date from the console:

whois your-site.com | grep -i "expir"

9. Who finds out when the site goes down

If the site goes down at night, who finds out first — you or your customers?

Availability has to be checked from outside, from another server: if the whole VPS is down, it can't report on itself. Checks from inside are what tell you the cause: disk, memory, a crashed container.

The minimum is an external service that opens your site every minute and writes to you when it doesn't respond. It matters that you get one message when the site goes down and one when it's back, not one every minute — otherwise in a week you'll stop reading them.

10. Failed services and containers

Sometimes the site works while something next to it quietly lies dead: a job queue, email sending, a scheduled backup.

systemctl --failed
docker ps -a --filter "status=exited" --filter "status=restarting"

A container stuck in Restarting, going round in a loop, is a common reason for “the site works, then it doesn't”. docker logs container-name --tail 50 shows why it keeps crashing.

In short

Going through this list once takes half an hour. Doing it every week across several servers gets tedious, and people start forgetting.

How vpsFocus does this

vpsFocus is a free desktop app that checks most of this list for you. You add a server over SSH, and the app:

• checks the server at the press of a button: open ports, including the ones Docker publishes past the firewall, SSH login and password-guessing attempts, the firewall, security updates and whether a reboot is needed. The check only reads: it leaves not a single file behind on the server;
• checks whether your sites serve .env and .git;
• watches disk space and inodes, certificate and domain expiry, and writes to you when something happens — once, not every five minutes;
• shows failed services and containers stuck in a restart loop;
• shows all of it, across all your servers, in one window.

The monitoring is installed on your own server and runs there: your data doesn't go anywhere, and it doesn't touch your sites — it only reads. You don't even need an account for any of this; an account is needed only for checking availability from outside, which physically can't be done from the same server.

Download vpsFocus