Module 13 · System Monitoring 45 min

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.

Lesson 11.1
htop — the new Task Manager

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.

htop — at a glance
CPU 1
74%
CPU 2
44%
CPU 3
71%
CPU 4
9%
Mem
3.9G / 8.0G
Swp
82M / 2.0G
Tasks: 138, 2 running Load avg: 0.42 0.31 0.18 Uptime: 03:47:12
Your programs System tasks Waiting for storage

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.

htop — getting started
# First: install htop if it's not already there
user@ubuntu:~$ sudo apt install htop -y

# Open it
user@ubuntu:~$ htop
# Inside htop — these are the keys you actually need:
F3 → Search by name (like Ctrl+F in Windows)
F5 → Show as tree (see which programs launched which)
F9 → Kill a program (like End Task in Windows)
F10 → Quit htop
u → Show only YOUR programs (filter by your username)

# Alternatively — a quicker snapshot without opening htop
user@ubuntu:~$ ps aux --sort=-%cpu | head -10
USER PID %CPU %MEM COMMAND
john 1234 45.2 8.1 /usr/bin/firefox
john 1456 2.3 1.2 bash
# The above shows the 10 most CPU-hungry programs right now

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.

Key TakeawayLots of blue bars in htop means your storage is the slow part — not the processor. F3 searches for a program by name. F9 stops a misbehaving one. F10 gets you out.
Lesson 11.2
Services — the programs that run by themselves

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.

systemctl — managing services
# Check if a service is running (replace nginx with any service name)
user@ubuntu:~$ systemctl status nginx
● nginx.service - Web server
Active: active (running) since today 08:00 ← GREEN = good
Active: failed ← RED = problem

# Start a service (turn it on)
user@ubuntu:~$ sudo systemctl start nginx

# Stop a service (turn it off)
user@ubuntu:~$ sudo systemctl stop nginx

# Restart (turn off then back on — good for applying changes)
user@ubuntu:~$ sudo systemctl restart nginx

# Make a service start automatically when the computer boots
user@ubuntu:~$ sudo systemctl enable nginx

# See ALL broken services in one go
user@ubuntu:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● myapp.service loaded failed failed My Application
# This is your first stop when something seems wrong

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

Key TakeawayWhen something stops working, start here: systemctl --failed. One command, every broken service listed. Then systemctl status servicename for the details. Green text = running fine. Red text = needs attention.
Lesson 11.3
Reading logs — your computer's diary

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.

journalctl — reading the computer's diary
# Watch logs as they happen — like a live news ticker for your computer
user@ubuntu:~$ journalctl -f
# Press Ctrl+C to stop following

# Read logs for ONE specific service only
user@ubuntu:~$ journalctl -u nginx
user@ubuntu:~$ journalctl -u nginx -f # follow nginx logs live

# Show only ERROR messages — your starting point when something breaks
user@ubuntu:~$ journalctl -p err

# Errors from THIS boot only (since the computer was last switched on)
user@ubuntu:~$ journalctl -b -p err

# Show logs from the last hour
user@ubuntu:~$ journalctl --since "1 hour ago"

# Show the last 50 lines only
user@ubuntu:~$ journalctl -n 50

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.

Key TakeawayThe three journalctl commands you'll use every day: 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.
Lesson 11.4
Disk space and memory — is there room left?

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

Checking disk and memory
# Check disk space — how full are your drives?
user@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 18G 30G 36% /
↑ ↑
Total size Percentage used — keep below 85%

# Find what's eating your disk space
user@ubuntu:~$ du -sh /var/log/* | sort -rh | head -10
4.2G /var/log/syslog ← a very big log file!
128M /var/log/nginx

# Check memory — how much RAM is being used?
user@ubuntu:~$ free -h
total used free available
Mem: 7.7Gi 1.2Gi 200Mi 6.1Gi
↑ ↑
Ignore this THIS is what matters
Swap: 2.0Gi 0B 2.0Gi
# If Swap "used" is not 0, your RAM is running low — investigate!
Key TakeawayCheck disk with 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.
Lesson 11.5
Load average — is the machine actually stressed?

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.

load average — at a glance
# Quick one-liner — uptime, users, and load
user@ubuntu:~$ uptime
14:22:01 up 3 days, 5:14, 2 users, load average: 0.45, 0.30, 0.20
1min 5min 15min

# How many CPU cores do I have?
user@ubuntu:~$ nproc
8
# So load 8.0 = fully busy, load 16.0 = severely overloaded on this machine
Key TakeawayLoad average = how many cores' worth of work is waiting in line, recently. Always compare it to 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.
Lesson 11.6
Cron — Linux's built-in reminder for running stuff on a schedule

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.

crontab basics
# Open YOUR crontab for editing (uses nano by default)
user@ubuntu:~$ crontab -e

# Inside, each line is: minute hour day month weekday command
* * * * * command-to-run
│ │ │ │ │
│ │ │ │ └── day of week (0=Sunday)
│ │ │ └────── month (1-12)
│ │ └─────────── day of month (1-31)
│ └──────────────── hour (0-23)
└───────────────────── minute (0-59)

# Real examples (paste these in)
0 2 * * * /home/user/backup.sh # 2:00 AM every day
*/15 * * * * /home/user/check-site.sh # Every 15 minutes
0 9 * * 1 /home/user/weekly-report.sh # 9:00 AM every Monday
@reboot /home/user/start-app.sh # When the system boots

# See what's currently scheduled
user@ubuntu:~$ crontab -l

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.

Key Takeawaycrontab -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.