Read system logs with journalctl

Ubuntu's systemd collects logs from every service into one journal. The journalctl command reads that journal, and its filters let you narrow thousands of lines down to the few that matter. This guide covers the filters you will use most.

Before you begin

• An Ubuntu 24.04 VPS with SSH access as a sudo user, such as alex. Ubuntu's default setup lets sudo users read the full journal.
• At least one service running, such as ssh, to practice on.
• A second terminal window, which helps when you use live following.

Step 1: Look at the most recent entries

The -n option limits output to the last N lines. --no-pager prints straight to the terminal instead of opening the less viewer. Without that option, press q to leave the viewer.

sudo journalctl -n 50 --no-pager

Oct 31 09:14:02 vps-example sshd[2231]: Accepted publickey for alex from 198.51.100.7 port 51422 ssh2
Oct 31 09:14:02 vps-example systemd[1]: Started session-14.scope - Session 14 of User alex.

Each line shows the time, the host name, the program, and the message.

Step 2: Follow new entries as they arrive

The -f option keeps the command running and prints new lines live, like tail -f. Open a second terminal, trigger the event you are interested in, and watch it appear. Press Ctrl+C to stop.

sudo journalctl -f

Step 3: Filter by service

The -u option selects one systemd unit. Here it shows SSH activity from the last hour. Unit names match the service names you see in systemctl, such as ssh, cron, or redis-server.

sudo journalctl -u ssh --since "1 hour ago" --no-pager

If you do not know the exact name, list the running services and search for part of it:

systemctl list-units --type=service | grep -i redis

Step 4: Filter by time

Use --since and --until to set a window. Dates and times can be written in plain English, such as "yesterday" or "2 hours ago", or as exact timestamps. The -b option limits output to the current boot, which is useful after a reboot.

sudo journalctl --since "2026-10-31 08:00" --until "2026-10-31 09:00" --no-pager
sudo journalctl -b --no-pager | head -n 40
sudo journalctl -b -1 --no-pager | tail -n 40

The -b -1 form shows the boot before the current one, which is where you look after an unexpected restart.

Step 5: Filter by priority

Every entry has a priority: emerg, alert, crit, err, warning, notice, info or debug. The -p option shows that level and anything more severe. Use err for real problems.

sudo journalctl -p err --since today --no-pager

If nothing matches, that is good news. An empty result means no errors were logged in that window.

Step 6: Combine filters and save the output

Filters combine, so you can ask for one service, a time range and a priority in one command. The -o short-iso option prints full ISO timestamps, which are easier to compare. You can also redirect the output into a file to share or keep.

sudo journalctl -u ssh -p warning --since "yesterday" -o short-iso --no-pager
sudo journalctl -u ssh --since today --no-pager > ~/ssh-today.log

The file is owned by your user, so you can read and copy it without sudo.

Step 7: Check how much space the journal uses

The journal grows over time. Check its size, which is reported as archived plus active data:

sudo journalctl --disk-usage

Archived and active journals take up 64.0M in the file system.

Ubuntu limits journal size by default. If you need to free space, you can remove entries older than a given age, for example two weeks:

sudo journalctl --vacuum-time=14d

Troubleshooting

• No entries shown: the unit name is probably wrong. Search with systemctl list-units --type=service and try again.
• Hint: You are currently not seeing messages from other users: run the command with sudo, since your account does not have full journal access.
• Old logs are missing after a reboot: check that /var/log/journal exists. Ubuntu stores logs there permanently, and a missing folder means logs live only in memory.
• Long lines are cut off: pipe the output into less -S, which scrolls sideways instead of wrapping.

Next steps

Use these filters whenever a service misbehaves, and pair them with the resource monitoring guide to see whether memory, disk or CPU is the cause.