Every service's log, one command, zero guesswork.
Your service died at 3am and /var/log/syslog is a wall of noise. journalctl is the tool that answers 'what happened, when, and to which unit' in a single query — if you know its filters.
journalctl reads the journal: the structured, binary log that systemd has been collecting since boot. Unlike plain-text logs, every entry carries metadata — the unit, PID, priority, boot ID, and a timestamp — which is why you can filter by service (-u), by severity (-p), by time (--since/--until), and by boot (-b) without ever touching grep. It is the front door to everything systemd knows about your machine.
Before systemd, debugging meant opening /var/log/syslog and hoping. journalctl collapses that into one query language. Want every error in the last hour? `journalctl -p err --since '1 hour ago'`. Want what a specific service logged at boot? `journalctl -b -u nginx`. It also survives reboots (the journal is persistent by default on most distros), so you can inspect last boot's crash with `-b -1`. For anyone running a server, this is the log tool.
journalctl -u ssh --since '10 minutes ago'
$ journalctl -u ssh --since '10 minutes ago' Sep 03 09:03:25 nuc sshd[633403]: Connection closed by authenticating user root 192.169.232.109 port 49254 [preauth] Sep 03 09:03:41 nuc sshd[633782]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.169.232.109 user=root Sep 03 09:03:43 nuc sshd[633782]: Failed password for root from 192.169.232.109 port 55592 ssh2 Sep 03 09:03:45 nuc sshd[633782]: Connection closed by authenticating user root 192.169.232.109 port 55592 [preauth]
-u filters to one unit. This is a live box being hammered by a brute-forcer on port 22 — journalctl makes that obvious in one line.
journalctl -p err --since '1 hour ago'
$ journalctl -p err --since '1 hour ago' Sep 03 09:04:19 nuc kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON init failed on port B Sep 03 09:04:19 nuc kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon Sep 03 09:04:19 nuc kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON init failed on port B
-p err shows only errors and worse. This machine has a flaky HDMI port driver spamming errors — exactly the kind of thing you want to surface, not bury.
journalctl -n 5
$ journalctl -n 5 Sep 03 09:01:16 nuc kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon Sep 03 09:01:17 nuc kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon Sep 03 09:01:21 nuc sshd[630751]: Connection closed by 192.169.232.109 port 51692
-n 5 is the tail of the journal — the last 5 lines. Add -f to follow live, like tail -f.
journalctl --disk-usage
$ journalctl --disk-usage Archived and active journals take up 2.4G in the file system.
The journal is binary and grows. 2.4G here — check yours, and cap it with journald.conf's SystemMaxUse if it is ballooning.
| Flag | Meaning |
|---|---|
-u <unit> | show only entries from one systemd unit, e.g. -u nginx |
-p <level> | filter by priority: emerg, alert, crit, err, warning, notice, info, debug |
--since / --until | time filter, e.g. '1 hour ago', 'yesterday', '2026-09-01 08:00' |
-b [n] | show a specific boot: -b is current, -b -1 is the previous boot |
-n <num> | show the last N lines (default 10) |
-f | follow — keep printing new entries as they arrive, like tail -f |
-o <format> | output format: short, json, json-pretty, cat, etc. |
journalctl is the query front-end for systemd's journal, which Lennart Poettering and the systemd team introduced in 2010 as part of the systemd init system. It replaced the scattered, plain-text /var/log files with a single structured, binary log that records metadata alongside each message. The name is simply 'journal' plus the standard 'ctl' (control) suffix systemd uses for its management tools.
The journal is not just text — each entry carries structured fields like _PID, _BOOT_ID, and SYSLOG_IDENTIFIER. That is why `journalctl -o json-pretty` can dump a full machine-readable record, and why you can filter on fields the plain-text logs never captured. It is a database, not a log file.