Reading journalctl properly

The systemd journal is indexed and structured, which means you can query it rather than scrolling. Most people use it as a text file with extra steps.

The filters that matter

journalctl -u nginx                  # one unit
journalctl -u nginx -f               # follow
journalctl --since "10 min ago"
journalctl --since "2026-09-17 09:00" --until "2026-09-17 09:30"
journalctl -p err                    # error and worse
journalctl -b                        # this boot
journalctl -b -1                     # the previous boot

They combine, and combining is where the value is. “Errors from this unit in the last hour” is one command:

journalctl -u myapp -p err --since "1 hour ago"

The previous boot

journalctl -b -1 -p err is the first thing to run after an unexplained reboot. It shows what the system was complaining about before it went down, which is usually the answer.

This only works if the journal is persistent. By default on many systems it is stored in memory and lost at reboot — precisely when you need it:

mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal
journalctl --flush   # move the running journal to disk now
journalctl --disk-usage

Structured output

The journal stores fields, not just text. That makes precise queries possible:

journalctl _PID=1234
journalctl _UID=33
journalctl -o json-pretty -n 1       # see every available field

Keeping it bounded

An unbounded journal will eventually consume the disk. Set a limit in /etc/systemd/journald.conf — SystemMaxUse=1G is a sensible default for most systems — so the retention decision is made deliberately rather than by the disk filling.

The habit

When something fails, do not start with -f. Start with the time window around the failure and filter by priority. You are looking for the first error, not the hundred consequential ones that followed it.