Most outages don't arrive out of nowhere. The server quietly fills up — memory creeping, disk shrinking, CPU pinned — and then the app falls over. Server monitoring is about watching those signs so you act on the warning, not the wreck.
The good news: you don't need a hundred metrics. Four resources cover the vast majority of trouble.
The four resources to watch
This is essentially Brendan Gregg's USE method — for each resource, watch its Utilisation, Saturation and Errors. The four resources:
| Resource | Watch for | "About to break" looks like |
|---|---|---|
| CPU | Utilisation & load average | Pinned near 100%, load above core count |
| Memory | Usage & swap | Creeping up (a leak), heavy swapping |
| Disk | Free space & I/O wait | Nearly full, high I/O wait times |
| Network | Throughput & errors | Saturated bandwidth, dropped packets |
CPU
High CPU isn't automatically bad — a busy server should use its CPU. The warning sign is sustained saturation: pinned at 100% with a load average higher than your core count, meaning work is queuing. That's when requests start to slow.
Memory
Memory is where the slow-motion disasters live. A steady climb that never comes back down is a leak — it'll eventually trigger the dreaded out-of-memory kill (often surfacing as a sudden 502 or 500). Heavy swap usage is another red flag: the server is out of RAM and paging to disk, which is brutally slow.
Disk
Two failure modes: running out of space (logs and temp files are the usual culprits — and a full disk takes down databases and apps hard) and high I/O wait (the CPU sitting idle waiting on a slow disk, which shows up as sluggish everything).
Network
Watch throughput (are you saturating the link?) and errors/drops (packet loss, which degrades everything quietly — see packet loss).
Watch trends, not just thresholds
A single reading tells you little; the trend tells you everything.
The most valuable server alert is a trend, not a snapshot. "Memory has been climbing for 6 hours" warns you before the crash; "memory is at 90% right now" might just be a busy moment. Watch the direction, and you fix things on a calm afternoon instead of at 3am.
This is also where predictive alerting shines — "disk full in ~4 hours at this rate" beats "disk full" by exactly four hours.
Server vs. uptime monitoring
These complement each other:
| Server monitoring | Uptime monitoring | |
|---|---|---|
| Looks at | Internal resources (CPU, RAM…) | External availability |
| Catches | Trouble building up | The site being down now |
| Best for | Prevention, capacity | Detection, alerting |
You want both: server metrics to see the storm coming, uptime checks to confirm what users actually experience.
The bottom line
| Resource | The headline risk |
|---|---|
| CPU | Sustained saturation → queued, slow requests. |
| Memory | Leaks and swap → out-of-memory crashes. |
| Disk | Full disk or I/O wait → hard failures, slowness. |
| Network | Saturation or drops → quiet degradation. |
Watch those four, focus on trends over snapshots, and most "the server fell over" surprises become "we saw it coming and added headroom." Pair it with uptime monitoring for the full picture.