How to Monitor CPU and RAM Usage on Linux

CPU and memory figures are easy to collect and easy to misread. A busy CPU may be doing useful work, while high memory use may mostly be filesystem cache. This guide shows how to capture the right evidence, interpret it in context, and create alerts that lead to useful action.

Decide what you are trying to detect

Monitoring should answer a specific operational question. For CPU and RAM, common questions include:

• Is the host unable to keep up with current work?
• Is one service consuming an unexpected share of resources?
• Is memory pressure causing swap activity or process termination?
• Did a release, scheduled task, or traffic event change resource use?

Write down the server’s role and expected busy periods first. A worker that runs at high CPU during a nightly job can be healthy. The same pattern on an otherwise idle web server may deserve investigation. Your baseline—not a generic percentage—is what makes the distinction.

For a broader host workflow that includes storage and network checks, read how to monitor Linux server performance.

Inspect CPU usage from several angles

top provides a live view of load, CPU categories, and processes:

top

Press 1 in many versions of top to display individual CPUs. Its summary splits CPU time into categories such as user work (us), system work (sy), idle (id), and I/O wait (wa). The split matters. High user or system time points toward runnable work; high I/O wait suggests tasks are delayed by storage activity.

For a compact repeating sample, use:

vmstat 1

The r column is the number of runnable tasks and b is the number blocked waiting for I/O. Read these with the CPU columns rather than in isolation. A host can show an elevated load average because many tasks are blocked, even if CPU utilization is not high.

To find current CPU consumers, sort the process table:

ps -eo pid,user,comm,%cpu,%mem --sort=-%cpu | head -n 15

Treat this as a starting point. Confirm the process identity, parent process, service unit, and start time before stopping it. A short-lived compiler, backup, or log rotation task can appear at the top of one sample without being the root cause.

Understand load average

uptime displays the one-, five-, and fifteen-minute load averages:

uptime
nproc

Compare load with the number of logical CPUs, then validate it with top and vmstat. Rising load, sustained CPU saturation, and a growing runnable queue together are stronger evidence of compute pressure than load alone. Rising load plus high I/O wait calls for a storage investigation instead.

Measure memory pressure, not just used memory

Start with:

free -h

On Linux, memory used for cache can be reclaimed when applications need it. The available figure is generally more informative than the simple used-memory total because it estimates memory that can be allocated without swapping.

Also examine swap:

swapon --show
vmstat 1

Configured swap is not automatically a fault. Repeated paging activity during a workload, a shrinking amount of available memory, and worsening latency are more useful signs of pressure. vmstat shows swap-in and swap-out activity in its si and so columns; sustained nonzero values during normal operation warrant investigation.

To identify memory consumers, change the sort:

ps -eo pid,user,comm,%cpu,%mem,rss --sort=-rss | head -n 15

The rss value represents resident memory, which is often more useful than virtual memory when comparing active processes. Shared memory and language runtimes make process totals imperfect, so use this output to identify candidates rather than to calculate an exact host total.

Check for out-of-memory events

When Linux cannot reclaim enough memory, the kernel may terminate a process. Inspect recent kernel messages:

journalctl -k --since "24 hours ago" | grep -iE 'out of memory|killed process'

If you find an event, record the timestamp, process, and preceding workload. Then check service logs, container limits if applicable, and recent changes. Increasing RAM can be appropriate, but it is not a substitute for finding an unbounded queue, memory leak, or limit set too low for the service.

Teams running containers should also distinguish host pressure from a container limit. A container can be terminated after reaching its own limit while the host still has free memory. Docker container monitoring is useful when that separation is part of your environment.

Build alerts around duration and impact

An alert is helpful only when it asks someone to do something. Rather than alerting on every brief peak, alert on sustained pressure and pair it with a response note.

A practical initial set might include:

1. CPU remains above the normal busy range for several consecutive collection periods.
2. Available memory remains low and swap activity is occurring.
3. An out-of-memory event is detected or a critical process has stopped.
4. High load occurs with I/O wait, prompting a disk-path check.

Set thresholds from observed behaviour and service requirements. Revisit them after deployments, seasonal workload changes, or incidents. Include the server name, affected metric, current value, duration, and a dashboard or runbook destination in the alert message when your tooling supports it.

CloudStats provides Linux server monitoring for tracking host health and can notify you by email when configured conditions are met. A host-level alert is strongest when it is correlated with a service-level signal; use website monitoring for an external view of a web service.

Use a repeatable investigation sequence

When an alert arrives, resist the urge to restart immediately. Follow a consistent sequence:

1. Check whether users are affected and identify the scope.
2. Note the start time and compare it with deploys, cron jobs, backups, and traffic changes.
3. Inspect CPU categories, load, available memory, swap activity, and top processes.
4. Check system and application logs for the same interval.
5. Apply the smallest safe mitigation, then observe whether the signal returns to baseline.

Save key timestamps and command output in the incident record. That evidence helps distinguish an isolated burst from a recurring pattern and makes the next response faster.

Review trends after the immediate issue

One live sample explains only the present moment. Review charts and logs over hours or days to find gradual memory growth, a recurring scheduled spike, or CPU pressure after a specific deployment. Keep the monitoring set focused: metrics should either identify a bottleneck, validate a service outcome, or trigger a documented response.

With a baseline, contextual commands, and duration-based alerts, CPU and RAM monitoring becomes a diagnostic tool rather than a stream of alarming numbers.