---
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
---

[All posts](/blog) [Monitoring](/blog/category/monitoring) Feb 18, 2026 · 3 min read · WatchFor Team

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

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.

[#monitoring](/blog/tag/monitoring)[#servers](/blog/tag/servers)[#basics](/blog/tag/basics)

## Monitor your servers & network

Ping hosts worldwide for reachability, latency and packet loss, with multi-region confirmation before you're alerted.

[Learn more](/ping-monitoring)[Start free](/auth/sign-up)

Share this article

---

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