GuidesLinux server

Linux server monitoring: what to watch and how

Updated 17 October 2026 · 8 minute read

Linux server monitoring comes down to a short list: CPU (load average and steal time as well as utilisation), available memory and swap activity, disk space and inodes, disk I/O wait and latency, network traffic and errors, the systemd services your applications need, and errors in the system journal. Measure them every 15 to 60 seconds, keep the history, and alert when a value stays past a threshold for several minutes.

This guide explains what each metric means, which built-in commands show it, and where to set your first alerts.

The key Linux server metrics

CPU, load average and steal

CPU utilisation shows how busy the processors are, split into user, system, I/O wait (wa) and steal (st) time. High utilisation alone is not a fault if work still finishes on time.

The load average is the average number of tasks running or waiting over 1, 5 and 15 minutes. On Linux it also counts tasks waiting for disk, so a high load with idle CPUs usually means a storage problem. Always read it against the number of cores (nproc): a load of 8 is busy on 2 cores and comfortable on 16.

Steal is time a virtual machine wanted the CPU but the hypervisor gave it to another guest. Sustained steal means the VM is short of real CPU, and no tuning inside the guest will fix it. On burstable cloud instances, it can also mean CPU credits have run out.

Memory: available, not free

Linux uses spare memory as a page cache, so the free column is almost always low on a healthy server. That is normal. The number to watch is available: an estimate of how much memory new work can use without swapping, including cache that can be dropped. Alert on low available memory, never on low free memory.

When memory really runs out, the kernel's OOM killer ends a process, often the largest one, which is usually your database or application. Those events are recorded in the kernel log.

Swap

How much swap is used matters less than how much is moving. A little swap used and left alone is harmless. Pages constantly swapped in and out (the si and so columns in vmstat) mean the server is short of memory and everything slows down.

Disk space and inodes

Check space on every mounted file system. A full root file system breaks package updates, logging and often SSH sign-in. Check inodes too. Each file uses one, and a file system with millions of small files (session files, mail queues, cache directories) can run out of inodes while df -h still shows free space. Writes then fail with "No space left on device".

Disk I/O wait and latency

I/O wait (wa) is CPU time spent idle while waiting for disk. A sustained high value means storage is the bottleneck. For detail, iostat -x shows per-device r_await and w_await (average milliseconds per read and write), the queue size (aqu-sz) and %util. On SSD, NVMe and cloud volumes, %util near 100% does not always mean saturation, because these devices serve many requests in parallel. Latency is the better guide.

Network

Watch throughput against link or instance limits, and the error and drop counters on each interface. Errors and drops should stay at or near zero. Also keep an eye on connection counts: a growing number of sockets in TIME-WAIT or CLOSE-WAIT can point at an application that does not close connections.

systemd services

Most server software runs as a systemd unit. A unit in the failed state, or one that restarts again and again, needs attention even if it is running at this moment.

Journal errors

The systemd journal collects messages from the kernel and every service. Errors at priority err and above, OOM kills, file system errors and disk errors are the lines worth alerting on.

Built-in commands to check a Linux server

Load, cores and a live view of processes (in top, press 1 for each core, and look at wa and st on the CPU line). htop gives a friendlier view if it is installed:

uptime
nproc
top

CPU, memory, swap and I/O wait every 5 seconds, five times. Watch r (runnable tasks), si/so (swap in and out), wa and st:

vmstat 5 5

Per-device disk latency and use, skipping idle devices. iostat comes in the sysstat package:

iostat -xz 5 3

Memory in megabytes; read the available column:

free -m

Disk space and inodes per file system, and the largest directories on the root file system:

df -h
df -i
sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail

Socket summary, listening ports and interface counters with errors and drops:

ss -s
sudo ss -tulpn
ip -s link

Failed units, and the status of one service:

systemctl --failed
systemctl status nginx

Errors since the last boot, warnings in the last hour, one service today, and kernel OOM kills:

journalctl -p err -b
journalctl -p warning --since "1 hour ago"
journalctl -u nginx --since today
journalctl -k | grep -i "out of memory"

Sensible alert thresholds

Use these as a starting point, then adjust them once you know each server's normal pattern. Require each condition to last several minutes before alerting.

On large disks a percentage can be misleading: 10% free on a 4 TB volume is 400 GB. For those, alert on hours until full or on a fixed amount of free space instead.

Why a central tool helps

These commands are the right tools for diagnosing one server. They do not keep history, they do not alert anyone, and they do not compare servers. Home-grown cron scripts fill some of the gap but break quietly. Once you run more than a handful of servers, a central monitoring tool that collects the same metrics and journal entries from every machine, keeps the history and sends alerts saves real time. Whatever you choose, prefer an agent that runs as an unprivileged service, needs no inbound ports and has bounded resource use.

Monitor Linux servers with Televane

Televane infrastructure monitoring uses an agent that runs as a hardened systemd service with its own unprivileged user, a read-only file system view and a memory cap. It works on systemd-based distributions such as Ubuntu, Debian, RHEL, Rocky, AlmaLinux, Amazon Linux and SUSE, on x86-64 and 64-bit ARM. It sends CPU, memory, disk, network and top-process metrics every 15 seconds, connects outbound only and opens no ports.

1. Create a free account. New organizations get a 14-day Pro trial without a card.
2. In the portal open Add data, choose Linux and copy the installation command.
3. Run it in a shell with sudo. Check it with systemctl status observability-agent; the server appears under Hosts within a minute or two. See the Linux agent guide.
4. To collect the journal, enable journald in /etc/observability-agent/agent.json with the units you care about and a minPriority such as warning. Lines appear in Logs with secrets masked on the server.
5. In Alerts, start from templates such as Host CPU critical and Host not reporting, and add log alerts for OOM kills or service failures. Notifications go to email, Slack, Microsoft Teams, PagerDuty or webhooks. See alerts and incidents.

For deeper checks such as inode use, steal time and per-device latency, df -i, vmstat and iostat remain the quickest tools on the server itself. Televane charges for the data you send, with no per-host fees; see pricing.

Frequently asked questions