VPS Monitoring Basics for Small Sites

Moving from shared hosting to a VPS feels like a promotion. More speed, more control, root access, a fraction of the price of managed hosting. It also comes with a job nobody mentions in the sales page: you’re now the sysadmin. If the disk fills up at 2 a.m., nobody at the hosting company will notice or care.

The good news is that monitoring a small VPS doesn’t need an enterprise stack. This guide covers the two layers every small site needs, the handful of numbers worth watching, and a setup you can finish in an afternoon.

Two layers: outside and inside

Monitoring has to answer two questions.

1. Can visitors reach my site? That’s external monitoring: checks from outside your server, the way a visitor or a search engine sees it.
2. Is my server healthy? That’s internal monitoring: CPU, memory, disk and services, measured on the machine.

You need both. Internal metrics can look perfect while DNS, an expired certificate or a firewall rule blocks every visitor. And an external check only tells you the site is down, not that the disk has been filling for a week.

Layer 1: External checks

Start here, because it catches the outages that matter most, with no software on the server.

• HTTP(S) uptime. Request your homepage (and one important page, like checkout or login) every minute or few minutes. Check the status code and response time.
• SSL certificate expiry. Even with auto-renewal, renewals fail. A warning 14 days out turns an outage into a to-do item.
• Domain expiry. The most embarrassing outage of all, and completely preventable.
• DNS records. An alert when your A or MX records change catches mistakes during migrations, and worse.
• Mail server, if you run your own.

An external server uptime monitor handles all of this from a server outside your network. Look for one that re-checks a failure before alerting, so you’re not woken up by a single dropped packet, and that tells you when the site recovers and how long it was down.

Layer 2: What to watch inside the server

You don’t need hundreds of metrics. These cover nearly every small-VPS failure:

Metric	Warn at	Act at	Why it matters
Disk space used	80%	90%	A full disk crashes databases and stops logging. The most common VPS outage
Memory available	Under 15%	Under 5%	When memory runs out, Linux’s OOM killer stops processes, often MySQL
Swap in use	Steadily growing	Heavy and constant	A sign the server needs more RAM or a leak needs fixing
Load average	Above CPU core count	2× core count, sustained	Requests queue up and the site slows down
CPU	80% for 10+ minutes	95% sustained	Runaway process, bot traffic or an attack
Key services	—	Any stopped	nginx, PHP-FPM, MySQL, Redis: if one stops, the site breaks

Quick health check from the command line

When something feels off, these commands answer most questions in a minute:

uptime                     # load averages for 1, 5 and 15 minutes
free -h                    # memory and swap
df -h                      # disk space per filesystem
sudo du -sh /var/log/*     # what’s filling the log folder
systemctl –failed         # services that crashed
journalctl -p err -b       # errors since the last boot
dmesg -T | grep -i oom     # processes killed for lack of memory

For ongoing internal monitoring, a lightweight agent such as Netdata gives you live graphs and alerts with almost no setup. If you outgrow it, Prometheus with node_exporter and Grafana is the standard next step. Many VPS providers also offer basic CPU, bandwidth and disk graphs in their control panel, which are worth enabling.

Prevent the usual suspects

Monitoring tells you about problems. A few small habits stop most of them from happening.

1. Rotate logs. Check that logrotate covers your web server, app and any custom logs. Unrotated logs are the top cause of full disks.
2. Restart services automatically. In systemd units, set Restart=on-failure so a crashed service comes back on its own.
3. Install security updates automatically. On Debian and Ubuntu, unattended-upgrades handles security patches.
4. Block brute-force attempts. fail2ban bans IPs that hammer SSH or your login page, which also saves CPU.
5. Back up, off the server. Provider snapshots are convenient, but keep a copy somewhere else too. Test a restore at least once.
6. Size swap sensibly. A small swap file gives the server breathing room before the OOM killer steps in.

Set up alerts you’ll actually act on

• Send alerts where you look. A dedicated Slack, Discord or Telegram channel works better than an email folder you never open.
• Separate warnings from emergencies. “Disk at 80%” can wait until morning. “Site down” can’t.
• Avoid false alarms. Confirmation re-checks and sensible thresholds keep alerts trustworthy. An alert channel people ignore is worse than none.
• Get recovery notices too. Knowing an outage lasted 4 minutes, not 40, changes what you do next.

An afternoon starter plan

1. Add external uptime checks for your homepage and one key page, plus SSL and domain expiry. (20 minutes)
2. Install a lightweight monitoring agent and set alerts for disk, memory and stopped services. (30 minutes)
3. Check logrotate, enable unattended-upgrades and set Restart=on-failure on key services. (30 minutes)
4. Set up off-server backups and test restoring one file. (1 hour)
5. Create a public status page if customers depend on your site. (15 minutes)

FastPing’s free plan, for example, covers three monitors, enough for a site, its certificate and its domain, with alerts to email, Slack, Discord or Telegram.

A VPS gives you control. Monitoring is what lets you enjoy it without wondering whether the site is up every time you close your laptop.