"The site is slow" and "we got a 500 error" almost always have a cause that shows up in the server's numbers, as long as someone is looking. This guide explains which metrics matter, how to read them on Linux and which thresholds signal trouble.
CPU and load average
The uptime command (or top) shows three load average numbers: the 1-, 5- and 15-minute averages of processes running or waiting for CPU and disk.
$ uptime
14:02:11 up 32 days, load average: 3.84, 2.10, 1.75
$ nproc
4Rule of thumb: compare the load with the number of cores. On a 4-core machine, a load of 3.8 is close to the limit; 8 means there is twice as much work as the CPU can handle. If the load is high but CPU usage is low, the bottleneck is usually disk (check iowait in top).
Memory: "available" is the number that matters
$ free -h
total used free shared buff/cache available
Mem: 3.8Gi 1.9Gi 210Mi 45Mi 1.7Gi 1.6Gi
Swap: 2.0Gi 120Mi 1.9GiLinux uses free memory as disk cache, so a low free value is normal. Watch the available column instead. Warning signs:
- available consistently below 10% of total;
- swap growing steadily, which slows everything down;
- OOM killer messages (
dmesg | grep -i oom) killing MySQL or PHP-FPM.
Disk: the #1 cause of sudden outages
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 80G 76G 4.0G 95% /
# what is taking up space?
$ du -xh / --max-depth=2 2>/dev/null | sort -h | tail -15When the disk is full, databases stop writing, PHP sessions fail and the web server returns 500 errors. The usual suspects: logs without rotation, piled-up local backups, application caches and old Docker images. Also check inodes with df -i: millions of small files can exhaust them even when there is free space.
Threshold reference table
| Metric | Healthy | Warning | Critical |
|---|---|---|---|
| Load (÷ cores) | < 0.7 | 0.7 – 1.0 | > 1.0 sustained |
| Available memory | > 20% | 10 – 20% | < 10% or OOM |
| Swap used | ~0 | Growing | > 50% |
| Disk used | < 75% | 75 – 90% | > 90% |
From one-off commands to continuous monitoring
The commands above answer "how is it right now?". To prevent incidents, you need history (is the disk growing 2% a day?) and a view of all your servers together. That is where continuous monitoring comes in:
- EzServer collects CPU, memory, disk and load from each server periodically, over SSH and with no agent.
- A single dashboard with all your servers and trend charts.
- Android and iOS apps to check the health of your infrastructure from anywhere.
- The AI Assistant explains command output in plain language and suggests the next diagnostic step.
df -h → 2) free -h → 3) uptime → 4) systemctl --failed → 5) latest errors in journalctl -p err -n 50.