VPS Monitoring Basics for Small Teams

For a small VPS, monitor resource pressure and check a real page from outside the server. Send urgent alerts for failures that need action, and use trends to plan maintenance before capacity runs out.

The metrics that matter most#

On Linux, load average includes runnable tasks and tasks in uninterruptible sleep, often waiting for I/O. It is not CPU utilization. The useful rule of thumb is that if load consistently exceeds your total vCPU count, the server is queuing work and will feel sluggish. A brief spike during a backup is normal. A sustained level above your core count is a capacity signal.

Memory tells a sharper story. When RAM runs out, the Linux out-of-memory killer begins terminating processes to keep the server alive, and it tends to pick the largest ones, which frequently means the database or the PHP process manager. Heavy swap usage is the earlier warning: it means memory has run out and the server has started using disk as a poor substitute, which slows everything down.

Disk space fails in two ways. A drive can run out of bytes, or it can run out of inodes, the file pointers a filesystem needs. A server holding millions of tiny cache or log files can report free space while still failing to create anything new. Tracking both avoids a confusing outage.

None of these numbers needs expert interpretation on day one. What matters is a baseline, meaning knowing what normal looks like on your server, because every threshold is really a deviation from that normal. A stable load still needs to be checked against response times and resource pressure. The same figure on a usually quiet server indicates a change worth investigating.

External checks and internal agents#

There are two complementary kinds of monitoring. An external check, sometimes called a synthetic check, requests a page from outside every few minutes and records whether the server returned a successful response. It answers the only question a visitor cares about: is the site up?

An internal agent runs on the server itself and reports CPU, memory, disk input and output, and process counts. It catches problems while they are still trends, such as memory climbing over a week or disk filling steadily, rather than waiting for them to become outages. Google's Site Reliability Engineering book frames this well with its four golden signals: latency, traffic, errors, and saturation. A small team that watches those four, plus disk space, has most of what it needs.

Alerts you can live with#

Alert fatigue quietly destroys monitoring. If every warning sends a push notification, the team learns to ignore notifications, and the one alert that mattered gets dismissed along with the rest. A common discipline is to reserve high-priority alerts, meaning SMS or push notifications that interrupt people, for hard outages and severe resource saturation.

Practical thresholds are simpler than they sound. Page a human when the site fails external checks for several minutes, when server errors persist, or when disk passes about ninety percent full. Everything else, including rising load, growing memory use, and a slow increase in response time, belongs on a dashboard or in a batched summary posted to team chat, where someone reviews it during working hours rather than reacting at night.

A simple starting routine#

You do not need a large platform to begin. Linux ships with tools that show all of this: top and uptime for load, vmstat for memory, iostat for disk. Ubuntu's server documentation covers them, and a weekly look at their output builds the intuition that dashboards later automate.

Pair that with an external uptime check from at least one independent location, and review the graphs after anything goes wrong. Keeping brief notes pays off as well: when an incident happens, record what the metrics showed, what fixed it, and how long it took. Three or four lines in a shared document gradually becomes a runbook that lets anyone on the team respond, rather than the one person who remembers the previous occurrence.

Over a few months this produces a small, quiet, reliable setup: advance warning of resource exhaustion before visitors notice anything, few false alarms, and a clear record of what happened when something did. That is the whole goal of monitoring for a small team.