---
title: Server Monitoring Basics: CPU, memory, disk and network
description: Before an app falls over, the server usually shows it coming. Here are the four resources to always watch — and what 'healthy' versus 'about to break' looks like for each.
canonical: https://watchfor.io/blog/server-monitoring-basics
---

# Server Monitoring Basics: CPU, memory, disk and network

2026-02-18 · WatchFor Team · Monitoring · monitoring, servers, basics

Before an app falls over, the server usually shows it coming. Here are the four resources to always watch — and what 'healthy' versus 'about to break' looks like for each.

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](/blog/observability-vs-monitoring)** — for each resource, watch its **U**tilisation, **S**aturation and **E**rrors. 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](/blog/502-bad-gateway) or [500](/blog/500-internal-server-error)). 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](/blog/what-is-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](/blog/uptime-monitoring-101) 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](/blog/uptime-monitoring-101) for the full picture.

---

Canonical page: https://watchfor.io/blog/server-monitoring-basics · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt