You’re staring at a sluggish website or a server that just feels “off,” and the question hits you: is this actually a resource problem, or am I imagining it? Before you can fix anything, you need to monitor CPU, RAM and disk usage on the machine so you’re looking at numbers instead of guesswork. The good news is you don’t need fancy software to get started — a handful of built-in commands will tell you almost everything you need to know in under five minutes. Later on we’ll also talk about why those manual checks eventually stop being enough, but let’s start with the basics.
This guide is written for beginners on purpose. If you’ve never opened a terminal on your server before, or you’ve only ever glanced at Task Manager without really knowing what the numbers mean, you’re in the right place. We’ll walk through the exact commands to run, what “normal” actually looks like, and where the danger line sits for each resource — CPU, RAM and disk — before talking about when it’s time to stop checking by hand.
Quick manual checks
Every operating system ships with tools that show you real-time CPU, memory and disk numbers. You don’t need to install anything to run these — they’re already on your machine.
Linux
The classic starting point is top, which gives you a live, refreshing view of CPU usage per process, load average, and memory summary right at the top of the screen.
top
Once top is running, a couple of keystrokes make it far more useful: press P to sort processes by CPU usage (highest first) or M to sort by memory usage, and press q to quit. The “load average” figure in the top-left corner is worth understanding too — it roughly represents how many processes are competing for CPU time, averaged over the last 1, 5 and 15 minutes. As a rule of thumb, if that number is consistently higher than the number of CPU cores your server has, you’re CPU-bound.
If it’s installed, htop is a friendlier version of the same thing — color-coded bars, mouse support, and easier sorting.
htop
For memory specifically, free -h gives you a clean, human-readable breakdown of total, used, free and available RAM (the -h flag is what converts raw bytes into MB/GB).
free -h
To check disk space across all your mounted filesystems, use df -h. This shows total size, used space, available space and the percentage used for every partition.
df -h
And for a combined snapshot of CPU, memory, and — importantly — disk I/O wait time, run vmstat with a delay so it keeps refreshing:
vmstat 1
If you want to know exactly which files or directories are eating your disk space, pair df -h with du:
du -sh /var/log/* | sort -rh | head -10
Finally, if you want dedicated disk I/O statistics rather than the general-purpose view vmstat gives you, install sysstat and run iostat with extended output, refreshing every second:
sudo apt install sysstat
iostat -xz 1
The column to watch here is %util — how busy the disk device actually is — alongside await, the average time (in milliseconds) requests spend waiting to be served. If %util is consistently near 100% and await is climbing, your storage is the bottleneck, not your CPU or RAM.
Windows
Press Ctrl+Shift+Esc to open Task Manager, then click the “Performance” tab. You’ll see live graphs for CPU, memory, disk and network, each with real-time percentages.
For more detail, open Resource Monitor directly from Task Manager (there’s a link at the bottom of the Performance tab), or launch it manually:
resmon
Resource Monitor breaks things down by individual process, so you can see exactly which service is hammering the disk or spiking CPU.
If you’re managing a server that runs Windows Server without a full desktop, or you want to log performance over time instead of just watching it live, use Performance Monitor (PerfMon):
perfmon
Inside PerfMon you can add counters like Processor(_Total)\% Processor Time, Memory\Available MBytes and LogicalDisk(_Total)\% Free Space to build a data collector set that records usage over hours or days — useful if a problem only shows up occasionally and you can’t sit and watch it happen.
If you’d rather stay in the command line, PowerShell can pull the same information without opening any windows at all. To see which processes are consuming the most CPU right now:
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
And to check which processes are using the most memory:
Get-Process | Sort-Object WS -Descending | Select-Object -First 10
For a quick look at free disk space on every drive letter:
Get-PSDrive -PSProvider FileSystem
These three commands alone cover most of what you’d otherwise dig through Task Manager or Resource Monitor to find, and they’re scriptable if you ever want to log the results to a file automatically.
What thresholds actually matter
Pulling up a monitoring tool is only half the job — the harder part is knowing which numbers actually mean trouble. A CPU briefly hitting 100% while a cron job runs isn’t a problem. A CPU sitting above 80% for several minutes at a time, night after night, usually is. Here’s a rough guide to the numbers worth paying attention to.
- Sustained CPU above 80%: occasional spikes are normal. What matters is CPU staying elevated for several minutes or longer — that’s when response times start to degrade and requests begin queuing.
- RAM headroom: Linux will use “free” RAM for disk caching, so don’t panic at high “used” memory alone — check the
availablecolumn infree -hinstead. The real warning sign is swap usage climbing above zero on a server that shouldn’t be swapping at all. - Disk usage above 85%: once a volume crosses roughly 85-90% full, performance can degrade and you’re one log file or backup away from a full disk outage. Treat 85% as your cleanup trigger, not the point where things actually break.
- Inode exhaustion: a disk can report plenty of free space (
df -h) while still being unable to create new files, because it’s run out of inodes — the filesystem’s bookkeeping slots for files and directories. Check this separately withdf -i, especially on servers that generate huge numbers of small files (mail queues, session caches, log rotation gone wrong). - Disk I/O wait: in
vmstat, thewacolumn shows the percentage of time the CPU spends waiting on disk. A consistently high number here (much above single digits) means your bottleneck isn’t CPU or RAM at all — it’s a slow or overloaded disk, and no amount of adding RAM will fix it.
Why manual checks aren’t enough
Running top or opening Task Manager tells you what’s happening right now, on the one server you happen to be looking at, at the exact moment you happen to be looking. That’s fine for troubleshooting an active problem, but it falls apart the moment you need to know what happened at 3 a.m. last night, or you’re managing more than one or two machines.
Manual checks also miss the buildup. A disk that fills up gradually over three weeks, or memory that leaks a little more with every deploy, won’t show up as an obvious spike — it just creeps until the day it crosses a threshold and something crashes. By the time you notice by eye, you’re usually already in an incident, not ahead of one. That’s the real gap: manual checks are a snapshot, but resource problems are usually a trend.
A few concrete situations make this obvious:
- You’re asleep when it happens. A traffic spike, a runaway backup job, or a bad deploy at 2 a.m. won’t wait for business hours. Without automated alerting, you find out from an angry customer, not from your monitoring.
- You’re managing more than one server. Running
topacross ten servers in ten separate SSH sessions isn’t a workflow, it’s a chore — and it’s one you’ll quietly stop doing after the first busy week. - You need history, not just a snapshot. When someone asks “why was the site slow yesterday afternoon,” a live view of
topright now can’t answer that. You need graphs of what happened, logged over time. - Slow leaks don’t look urgent until they suddenly are. Memory creeping up 1% a day looks like nothing on any single check — until three weeks later, it’s the reason your application crashed.
None of this means manual commands are useless — they’re still the fastest way to confirm a problem someone reports, or to sanity-check a graph a monitoring tool is showing you. But relying on them as your only method of “keeping an eye on things” means you’re only ever finding out about problems after they’ve already started.
Tools that automate this for you
Once you’re past the “just checking one server occasionally” stage, it makes sense to let something watch the numbers continuously and alert you before things break, instead of you refreshing top every hour. A few solid options, depending on how hands-on you want to be:
- Netdata — free, open-source, and shockingly easy to get running. It gives you real-time, per-second graphs for CPU, RAM, disk and practically everything else, straight out of the box with almost no configuration.
- Zabbix — a mature, fully open-source platform built for monitoring many servers at once, with flexible alerting rules and long-term historical data. It has a steeper learning curve but scales well for teams managing real infrastructure.
- Site24x7 — a hosted, all-in-one option that combines server monitoring with website and application checks, so you’re not stitching together multiple tools for a small setup.
- Datadog — the enterprise-grade choice, with deep integrations, dashboards and anomaly detection, aimed at teams running larger or more complex environments.
If you’re not sure which direction fits your setup, it’s worth browsing a roundup of best server monitoring tools to compare free and paid options side by side before you commit to one.
FAQ
How often should I check CPU, RAM and disk usage manually?
For a single small server, a quick glance once a day or whenever something feels slow is usually enough. Once you’re running anything customer-facing or managing multiple servers, manual checks stop scaling and it’s time to set up automated alerting instead.
What’s a normal amount of RAM usage for a server?
It’s normal — even healthy — for Linux servers to show high “used” memory because the OS caches disk data in RAM to speed things up. Focus on the “available” figure in free -h and on swap usage, not the raw “used” number.
Why does my disk show free space but I still can’t create new files?
You’ve likely run out of inodes, not disk space. Run df -i to check inode usage separately from df -h‘s space usage — this is a common (and confusing) issue on servers handling lots of small files.
Is 100% CPU usage always bad?
No. Brief spikes to 100% during a backup job, a deploy, or a burst of traffic are completely normal. The problem is CPU usage staying high for sustained periods, which points to genuine resource pressure rather than a momentary task.
Do I need a monitoring tool if I only have one server?
Not necessarily at first — manual checks with top, free -h and df -h can cover you early on. But even a single production server benefits from something lightweight like Netdata, since it catches slow-building problems (like a filling disk) long before you’d notice them by eye.
Manual commands are great for a quick gut check, but once uptime actually matters, it’s worth setting up something that watches these numbers around the clock — take a look at see the best all-round server monitoring platforms to find one that fits your setup.