It’s not enough just to set up a VPS: you also need to keep an eye on it. Most outages don’t happen out of the blue; there are warning signs: a disk filling up slowly, a process using more and more memory, a recurring error in the log, or a certificate due to expire at the weekend. If you spot these in time, you’ll notice the problem before your visitors do and can prevent the outage.

In this guide, we summarise what you should monitor on a VPS, what tools to use, how to set up alerts so you don’t get swamped with notifications, and what to do with the data you collect.

What should you measure?

External access

The most important question is: can visitors access the website? This needs to be monitored from outside the server, because if the server goes down, even its own monitoring system won’t be able to detect it. An external uptime monitor checks the site every few minutes (and may even search for a keyword within it), and if it doesn’t respond, it triggers an alert.

Processor

• CPU usage: sustained usage consistently above 80–90% indicates that there is insufficient processing power or that a process has run amok.
• Load average: the average number of processes waiting to run over 1, 5 and 15 minutes. It is cause for concern if it consistently exceeds the number of vCPUs. Our knowledge base article explains what load means in Linux.
• Steal time (st): On a VPS, this indicates how long the virtual machine has been waiting for the physical processor. A consistently high value indicates that the physical server is overloaded; on a KVM VPS with guaranteed resources, this should be low.
• I/O wait (wa): the amount of time the processor spends waiting for the disk. If this figure is high, the storage is the bottleneck.

Memory

• Used and available memory: Linux uses free memory as a cache, so the ‘free’ value may be low even when everything is working correctly. Keep an eye on the ‘available’ value.
• Swap: if the system is swapping regularly, it means there is not enough memory and it is slowing down.
• OOM killer: if memory runs out, the kernel terminates a process (often the database). Entries in the log stating ‘Out of memory’ indicate this; an article discusses this OOM killer and the creation of a swap file.

Disk

• Free space: a full hard drive is one of the most common causes of downtime (logs, backups, uploads). Be on the alert when it reaches 80–85 per cent.
• Inodes: with a large number of small files (cache, sessions), you may run out of inodes before you run out of disk space.
• Disk operations (IOPS, throughput) and latency.

This article explains how to monitor disk usage using the du and df commands.

Network

Incoming and outgoing traffic, number of connections, errors. A sudden spike in traffic could be the result of a successful campaign, but it could also be an attack or spam being sent from a compromised server.

Services and applications

• Are the essential services (web server, PHP-FPM, database, email) running?
• Application response time and the proportion of failed requests (5xx).
• Slow database queries.
• SSL certificate expiry, domain expiry.
• Backups: has the most recent backup been completed?

Blogs

System and application logs (journald, /var/log, and the web server’s error and access logs) show what has happened. Recurring errors, failed login attempts and unusual requests serve as early warnings. Our article on reading logs, which covers journalctl and the /var/log directory, and our blog post on analysing web server logs provide further details.

Tools

Quick diagnosis via the command line

• htop or btop: processes, CPU and memory in real time. This article discusses how to use top and htop.
• vmstat 1: CPU, memory, swap, I/O wait and steal per second.
• iostat -x 1 (sysstat package): disk load and latency.
• df -h, df -i, du: disk space and inodes.
• ss -tulpn: open ports and connections.
• journalctl -p err -b: system errors since the last boot.

These are needed for troubleshooting; the following tools are designed for continuous monitoring and alerts.

Monitoring systems

Tool	What is it for?	Comment
Netdata	Detailed, real-time monitoring in just a few minutes, complete with alerts	For one or two servers, it’s the simplest option; open-source, with cloud services too
Prometheus + Grafana	Time-series monitoring, customised dashboards and alerts	With node_exporter, system metrics can be measured, and with exporters, applications can be monitored too; ideal for environments with multiple servers
Zabbix	Comprehensive enterprise monitoring	For many servers, more complex configurations
Glances	Simple, clear terminal and web interfaces	For a quick overview
Monit	Service monitoring and automatic restart	Small and reliable – see below

External availability monitoring

• Uptime Kuma: a self-hosted, open-source uptime monitor with a neat status page. Run it on a different server, not the one it’s monitoring.
• Services include: UptimeRobot, Better Stack, HetrixTools and similar tools; even the free plan offers checks every few minutes.

Alerts

A good alert sounds when action is required, and only then. Here are a few tips:

• Threshold and duration: don’t set an alert for a momentary spike, but for a sustained condition (for example, ‘CPU above 90% for 5 minutes’).
• Two levels: warning (for example, when disk space reaches 80 per cent) and critical alert (at 95 per cent).
• Focus on the symptom, not just the cause: ‘the website isn’t responding’ is more important than ‘the load is high’.
• Channel: email alerts can easily get lost; send critical ones to mobile devices (push notifications, Telegram, Slack, SMS).
• Don’t set unnecessary alerts: if you regularly don’t need to take any action on an alert, reconfigure or delete it, otherwise you’ll end up ignoring the important ones too.

Some tried-and-tested starting thresholds:

Key figures	Warning	Critical
Disk usage	80%	90–95%
Available memory	Under 15%	Under 5 per cent
CPU (continuous)	80%	95%
Load (persistent)	Number of vCPUs	Twice the number of vCPUs
SSL expiry	21 days	7 days
Website availability	–	2–3 consecutive failed checks

Automatic recovery

Monit can automatically restart a service that has stopped and notify you. For example, for the web server:

check process nginx with pidfile /run/nginx.pid
  start program = "/usr/bin/systemctl start nginx"
  stop program  = "/usr/bin/systemctl stop nginx"
  if failed host 127.0.0.1 port 80 protocol http then restart
  if 5 restarts within 5 cycles then alert

Automatic restart is merely a stopgap measure: if a service keeps crashing, you need to find the cause.

What should you do with the data?

• Low memory, regular swapping, OOM: adjust your applications (PHP-FPM process count, database buffer size), or upgrade to a larger plan.
• High CPU usage in a single process: find out which one it is and why (a plugin, a cron job, bot traffic, a hack).
• High I/O wait: slow queries, excessive logging, or a large backup running during working hours.
• Full disk: log rotation, deleting old backups, clearing the cache; if the du doesn’t show where the space is, this article on the hidden causes of a full disk will help.
• Common limits: on aWh’s KVM VPSs, you can upgrade to a larger plan via the client portal; we have a separate guide on scaling VPS resources.

The data collected is also needed for planning: weekly and monthly trends show when storage space or memory is running out, so you can upgrade in good time.

Who monitors the server?

On an unmanaged VPS, monitoring is your responsibility. If you don’t have the time or expertise, our managed VPS service takes care of server monitoring, alert management and troubleshooting for you. aWh’s KVM VPS servers come with guaranteed processor and memory resources, NVMe SSDs, daily backups and 99.9% uptime; thanks to these guaranteed resources, performance metrics are predictable and do not depend on the traffic of neighbouring customers.

Summary

Monitor availability from the outside, and CPU usage (along with steal and I/O wait times), memory, disk, network, services, certificates and backups from the inside. For one or two servers, Netdata and an external uptime monitor are sufficient; for more servers, use Prometheus and Grafana. Set up a few, well-defined alerts, and plan your expansion based on the trends.

Frequently Asked Questions

What is the easiest way to monitor a VPS?

An external uptime monitor (such as UptimeRobot or Uptime Kuma running on another server) and Netdata installed on the server. This can be set up in a matter of minutes and flags most issues in good time.

What does ‘steal time’ mean?

The amount of time the virtual machine spent waiting for the physical processor because it was busy with something else. This figure is low on KVM VPS with guaranteed resources; if it remains consistently high, please notify your provider.

Does monitoring slow down the server?

Lightweight agents (node_exporter, Netdata) place a negligible load on the system. On a very small VPS, choose a lighter tool and avoid collecting data unnecessarily frequently.

How often should I check my website’s availability?

Every 1–5 minutes. Only send an alert after 2–3 consecutive failed checks, so that a momentary network fault does not trigger a false alarm.

Where should I store my monitoring data?

If possible, don’t use the same server that you’re monitoring: use an external service or a different server. That way, even if the server goes down, you’ll still be able to see what happened beforehand.

Is monitoring necessary even for a small VPS?

Yes, at least one external availability monitor and one disk space alert, because a full disk and service outages are the most common faults, even on small servers.

• vps
• monitoring
• server administration
• uptime
• guides