Module 13 · System Monitoring
Think of your Linux computer like a busy office. You want to know who's working, who's slacking, whether the filing cabinet is full, and whether the lights are on. This module shows you how to check all four — one step at a time, no jargon.
By the end of this module, you will:
- Use htop to identify processes consuming excessive CPU or memory
- Start, stop, restart, and check the status of systemd services
- Read and filter system logs using journalctl
- Diagnose disk and memory pressure using df -h and free -h
- Interpret the load average shown by uptime and the htop header
- Schedule recurring tasks with cron and crontab
If you used Windows, you already know this
On Windows you used Task Manager (Ctrl+Alt+Delete) to see what was running and Event Viewer to read error messages. Linux has the same things — they just look different and work from the terminal (the black text box). Same job. Different tools.
You know when your Windows machine slows down and you hit Ctrl+Alt+Delete to see what's hogging the memory? On Linux, the tool that does the same job is called htop. It's Task Manager's faster, friendlier cousin.
When you open htop, you see coloured bars at the top — one for each processor core in your computer. Green means your programs are using the processor. Red means Linux itself is doing heavy work. Blue is the interesting one: it means the processor is waiting around for the hard drive to catch up. If you see lots of blue, your storage is the slow part — not the chip.
Look at CPU 3 in the snapshot above — it's almost all blue. That processor isn't busy. It's just sitting there waiting for the disk to catch up. If you see lots of blue, the slow part is your storage, not the chip. Don't go buy a faster processor — check the disk first.
Below the bars you see a list of everything running right now — every program, every background task, every little helper. Don't panic. There will be a lot. Most are tiny helpers using almost nothing. The ones worth looking at are anything over 20% CPU or RAM.
Stopping a program that won't close. On Windows you click End Task. On Linux you use the kill command. Don't worry about the scary name — it's just a message you send to the program. The polite message is kill 1234 (swap 1234 for the program's ID number, which htop shows you). If the program ignores that, use kill -9 1234 — that's the force-quit, like pulling the plug out of the wall. Always try the polite version first.
Picture an office building. The lights come on by themselves every morning. The air conditioning hums all day. The alarm arms itself at night. Nobody flips a switch — these are automatic services that run in the background. Your Linux computer works the same way. Things like the web server, the database and the email program are all services. They start when the computer turns on, run quietly, and ideally you never have to think about them.
The tool that bosses these services around on Linux is called systemctl (say it "system control"). It lets you start, stop, restart and check on any service — like the control panel for the whole building. On Windows you'd open the Services panel (services.msc) or Task Manager. On Linux, one command does the lot.
One thing that catches people out: after you change a service's settings file, you have to run sudo systemctl daemon-reload before you restart the service. Think of it like saving a document before printing — if you don't save first, the printer uses the old version. daemon-reload tells Linux "please re-read the settings I just changed".
systemctl --failed. One command, every broken service listed. Then systemctl status servicename for the details. Green text = running fine. Red text = needs attention.Every time anything happens on your Linux computer — a program starts, you sign in, a web page loads, an error pops up — Linux writes it down in a log. Think of it as the computer keeping a diary. When something breaks, the diary tells you what happened and when. It's the single most useful tool for fixing problems.
On Windows you'd open Event Viewer to read these logs. It works, but you spend a lot of time clicking and filtering. On Linux there's one command — journalctl (say it "journal control") — that reads every log on the system. You can filter by time, by service name, by how serious the message is. Once you get the hang of it, you'll spot problems in seconds that took minutes in Event Viewer.
When something breaks and you have no idea where to start, run these two in order: first systemctl --failed (what's broken?), then journalctl -b -p err (what errors happened since the machine started?). Together they tell you what broke and why, usually inside a minute.
journalctl -f watches everything live, journalctl -u servicename -f watches one service live, journalctl -b -p err shows every error since the machine started. Learn those three and you can fix almost anything.On Windows, when your disk gets low you see a little warning balloon in the corner. Linux doesn't do that. If your disk fills up all the way, services just start quietly failing. A full disk is one of the most common reasons Linux machines start acting weird. Checking takes 30 seconds — make it a habit.
Memory works differently on Linux than you'd expect. Run free -h and the "free" column can look tiny — sometimes just 100MB on an 8GB machine. Don't panic. Linux uses any spare RAM to remember recently-used files so they load faster next time. The moment a program needs that memory, Linux hands it straight back. The number you actually care about is "available", not "free".
df -h — anything past 85% full needs a clean-up. Check memory with free -h — look at "available", not "free". If "Swap used" is anything other than zero, something is eating more RAM than it should.Three little numbers in the top-right of htop tell you whether your machine is taking it easy, working hard or genuinely overloaded. They're called the load average. You'll see them everywhere on Linux — in uptime, top, htop and most server dashboards. They look mysterious until someone explains them. Here's the explanation.
A load average of 0.45 0.30 0.20 means: over the last 1 minute the CPU was busy about 45% of one core's worth, over the last 5 minutes 30%, over the last 15 minutes 20%. The trick is to read the trend across the three numbers — climbing means things are getting worse, falling means a spike has passed.
The number to compare against is how many CPU cores your machine has. On a 4-core laptop, load 4.0 means "perfectly busy, no spare capacity left." Anything above your core count means programs are waiting in a queue for their turn — the machine is overloaded.
nproc (your core count). If the 5-min and 15-min numbers are climbing past your core count, you have a real problem — not just a quick spike.On Windows you'd open Task Scheduler to run a backup at 2am every night. On Linux the equivalent is called cron. It's a built-in service that runs commands on a schedule. No extra software, no install. Cron has been around since the 1970s and quietly does its job on millions of machines.
Every user has their own little list of scheduled jobs, called a crontab. You edit it with crontab -e. Each line in the list is one job — five time fields, then the command to run.
A handy trick: build your cron lines at crontab.guru. You paste a schedule in, and the site tells you in plain English when it'll run. Saves a lot of "did I write that right?" worry.
crontab -e opens your job list. Five time fields, then the command. @reboot runs once when the computer starts. crontab -l shows what's scheduled right now. Cron writes to journalctl like everything else, so that's where to look if a job doesn't run.