Reading server metrics — CPU, RAM, disk and load
Learn how to read server metrics — CPU usage, RAM, disk space and load average — and know what a healthy server actually looks like versus a warning sign.
Your server dashboard is full of numbers, but which ones matter and what's "normal"? This guide explains how to read the core server metrics — CPU, RAM, disk and load average — so you can tell a healthy server from one that's about to give you trouble.
In Servor, these numbers come from the agent as resource metrics. You'll see them on each server and can set thresholds that alert you when they cross a line.
Read trends, not snapshots
A single high reading rarely means anything — servers spike constantly. What matters is the trend: a number that climbs and stays up, or a spike that doesn't come back down. Always look at a metric over time before acting on it.
CPU usage
CPU tells you how much processing the server is doing, usually as a percentage of total capacity.
- Healthy: low to moderate most of the time, with brief spikes to high under load that fall back quickly.
- Warning sign: CPU pinned near 100% for minutes at a stretch, not seconds. That means requests are queueing and the machine can't keep up.
A short spike when a backup runs or traffic surges is normal. Sustained saturation is the problem — which is why you should alert on duration, not a single reading.
High CPU isn't always bad
A batch job or import should use the CPU it needs. Ask whether the load matches what the server is supposed to be doing right now. Unexplained sustained CPU is the red flag.
RAM (memory)
RAM is working memory. When it runs out, the server starts swapping to disk (slow) or the kernel starts killing processes (worse).
- Healthy: comfortable headroom, a stable or slowly-varying level that tracks your workload.
- Warning sign: a steady climb that never comes back down — the classic shape of a memory leak — or usage sitting near capacity with no room to absorb a spike.
On Linux, don't panic at 'low free memory'
Linux deliberately uses spare RAM for disk cache, so "free" memory often looks small on a healthy box — that cache is released instantly when apps need it. Watch available memory and the trend over time, not the raw "free" number.
Disk space
Disk is the metric most likely to cause a hard, ugly outage — and the easiest to prevent.
- Healthy: stable usage with clear headroom, growing predictably as you add data.
- Warning sign: a climb toward full, or a sudden jump (runaway logs, a stuck upload, a database that stopped rotating).
A full disk takes services down hard
When a disk hits 100%, databases refuse writes, logs stop, and services crash in ways that are slow and messy to recover from. Alert well before full — leave real headroom — so you fix it as a chore, never as an outage.
If disk is climbing, the usual culprits are log files, package caches, old backups, or
temporary files that never got cleaned up. The web terminal or a
quick command like du -sh /var/* will show you where the space
went.
Load average
Load average is a Unix/Linux metric showing how many processes are waiting to run, typically over 1, 5 and 15 minutes. It's often misread, so here's the key:
Compare load to the number of CPU cores. A load of 4.0 is fully busy on a 4-core
machine and overloaded on a 1-core machine.
- Healthy: load average at or below your core count — work is being handled as it arrives.
- Warning sign: load consistently above your core count, meaning processes are queueing and waiting for CPU time.
The three numbers show direction: if the 1-minute figure is well above the 15-minute one, load is rising right now; if it's below, a spike is subsiding.
| Cores | Load ≈ core count | Load well above cores |
|---|---|---|
| 1 | Fully utilised | Overloaded |
| 4 | Fully utilised | Overloaded |
| 8 | Fully utilised | Overloaded |
What "healthy" looks like at a glance
| Metric | Healthy | Investigate |
|---|---|---|
| CPU | Low/moderate, brief spikes that recover | Pinned near 100% for minutes |
| RAM | Stable with headroom | Steady climb that never drops, or near capacity |
| Disk | Stable with clear headroom | Climbing toward full, or a sudden jump |
| Load | At or below core count | Consistently above core count |
Turning metrics into alerts
Reading metrics by eye is fine for a quick check, but you don't want to be watching a dashboard. Set resource thresholds so Servor watches for you and alerts through your notification channels. Open your servers in Servor to set thresholds, and configure channels in alert settings.
Alert on sustained conditions
Set thresholds to fire on a condition that persists (for example, disk over a limit for several checks) rather than a single reading. See monitoring best practices for how to pick thresholds that mean something and avoid alert fatigue.