journalctl Cheat Sheet: Tail, Filter and Follow Linux Logs

Related on the site: Systemd Service Not Starting? How to Fix It.

journalctl in one line: journalctl -u <service> -f follows a live service log, journalctl -u <service> -n 100 shows the last 100 lines, and journalctl --since "1 hour ago" shows everything recent. That covers 90% of the "why is this service down" moments. The rest of this cheat sheet is the copy-paste patterns that save you from re-reading the man page at 2am — filtering by unit, time, priority and boot, plus the cleanup commands that stop a journal from eating your disk. Every command below runs as-is on any systemd distro (Ubuntu, Debian, Fedora, Arch).

What is journalctl and why not just read /var/log/syslog?

Old-school Linux logging wrote plain text files under /var/log — syslog, auth.log, messages. systemd replaced that with the journal: a binary, indexed log managed by systemd-journald. Plain grep cannot read it; journalctl is the only front door, and in exchange you get filtering by service, time, boot and severity without regex gymnastics.

The mental model is simple: the journal stores everything, and journalctl is the query tool. A service does not need its own log file — anything it writes to stdout/stderr while running under systemd lands in the journal automatically. That is why journalctl -u nginx works even when you have no idea where nginx configured its error log.

One caveat: on some minimal installs the journal is volatile (stored in /run, wiped on reboot) because /var/log/journal does not exist. Fix it once:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

How do I see the last 100 lines of a log?

-n limits output to the newest N lines (default is 10):

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

--no-pager matters more than it looks: without it journalctl opens less and your script, pipe or ssh one-liner hangs waiting for a keypress. Any command you pipe onward should carry it.

How do I follow logs live, like tail -f?

The -f flag is journalctl's tail -f — it streams new entries as they happen:

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

This is the command to run in a second terminal while you restart a service in the first one: systemctl restart nginx in one pane, journalctl -u nginx -f in the other, and the cause of the crash usually announces itself within seconds. I run this exact loop on my homelab every time a container or service misbehaves.

How do I show logs for a specific service?

-u filters by systemd unit:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # the exact-match alternative

Units can spawn helper units that keep the interesting output — a failing web app sometimes logs the real error under a different unit. If -u <service> shows nothing but the service clearly runs, find the actual unit name first:

systemctl list-units --type=service | grep -i <guess>

The same -u pattern works for timers (systemctl list-timers shows names) and user services — for anything running under systemd --user add --user:

journalctl --user -u pipewire -n 50

How do I filter logs by time?

--since and --until take timestamps, but they also accept forgiving relative phrasing:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Pair a time window with a unit and you have incident triage in one line: "what did the API log between 09:00 and when it fell over?" That is faster than any log aggregator for a single box.

How do I show only errors (or warnings)?

-p filters by priority, using syslog severity names:

journalctl -p err -b              # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

Priorities in descending order: emerg, alert, crit, err, warning, notice, info, debug. When a box is "acting weird", journalctl -p err -b --since today is the fastest sanity check — it answers "is anything actually failing?" without noise from routine info lines.

How do I see logs from the previous boot?

Services that crash at startup produce log lines before your current boot, and journalctl silently shows only the current one. -b selects boots:

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

This is the single most useful flag for "it broke and I rebooted it and now I can't see the error" — the error is still there, one boot back.

Quick reference: the flags worth memorising

How do I stop the journal filling my disk?

Check what it costs, then cap it:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

To make a cap permanent, set SystemMaxUse=500M under the [Journal] section in /etc/systemd/journald.conf, then sudo systemctl restart systemd-journald. Between the size cap and the boot filter above, the journal stays a tool rather than a slow disk leak.

journalctl vs dmesg vs /var/log — which do I check first?

• journalctl — application and service behaviour. Anything systemd manages is here, indexed and filterable. Default first stop.
• journalctl -k / dmesg — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• /var/log/<app>/ — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

The same workflow extends to local AI services — when an ollama serve unit stalls, journalctl -u ollama -n 100 shows the model load failure immediately, as covered in the Ollama vs LM Studio comparison.

That is the whole cheat sheet: -u for unit, -f to follow, -n for lines, --since for time, -p for severity, -b for boots. Six flags cover nearly every log question a Linux box will ask you.

This ships daily at mrsaynothing.dev — the full archive, every piece in 19 languages, zero missed days. New posts land in the newsletter the moment they ship: join it here. Code at GitHub.