Service logs in the systemd journal show why a daemon failed to start, restarted repeatedly, or ignored a configuration change after a short status summary stopped being specific enough. Reading the unit journal around the failure window is often the fastest way to separate an application error from a dependency, permission, or boot-order problem.
On a systemd host, service processes write standard output and standard error to systemd-journald by default, and journalctl can filter those records by unit name with -u or --unit. That unit filter also includes manager messages about starts, stops, reloads, and failures, which keeps the output centered on one service instead of mixing in the full system journal.
Most system service logs require sudo, while per-user services use journalctl --user -u unit.service instead. Older entries from earlier reboots appear only when the host keeps journal files after boot, typically under /var/log/journal, so hosts that use only volatile storage may show only the current boot.
$ sudo journalctl -u queue-worker.service -n 6 --no-pager Apr 13 13:13:43 server systemd[1]: Started queue-worker.service - Queue Worker Service. Apr 13 13:13:43 server queue-worker[197]: queue-worker starting Apr 13 13:13:43 server queue-worker[197]: queue backlog above soft limit Apr 13 13:13:43 server queue-worker[197]: queue-worker heartbeat 1 Apr 13 13:13:48 server queue-worker[197]: queue-worker heartbeat 2 Apr 13 13:13:53 server queue-worker[197]: queue-worker heartbeat 3
Replace queue-worker.service with the real unit name, such as nginx.service or ssh.service. If the exact name is unclear, use systemctl list-units --type=service --all or systemctl status to confirm it first.
$ sudo journalctl -u queue-worker.service --boot --since "1 minute ago" --no-pager -n 8 Apr 13 13:13:43 server queue-worker[197]: queue-worker starting Apr 13 13:13:43 server queue-worker[197]: queue backlog above soft limit Apr 13 13:13:43 server queue-worker[197]: queue-worker heartbeat 1 Apr 13 13:13:48 server queue-worker[197]: queue-worker heartbeat 2 Apr 13 13:13:53 server queue-worker[197]: queue-worker heartbeat 3 Apr 13 13:13:58 server queue-worker[197]: queue-worker heartbeat 4 Apr 13 13:14:03 server queue-worker[197]: queue-worker heartbeat 5 Apr 13 13:14:08 server queue-worker[197]: queue-worker heartbeat 6
--boot restricts the query to one boot, and --since accepts exact timestamps plus keywords such as today, yesterday, and now.
$ sudo journalctl -u queue-worker.service --follow --lines=4 --no-pager Apr 13 13:13:43 server queue-worker[197]: queue-worker heartbeat 1 Apr 13 13:13:48 server queue-worker[197]: queue-worker heartbeat 2 Apr 13 13:13:53 server queue-worker[197]: queue-worker heartbeat 3 Apr 13 13:13:58 server queue-worker[197]: queue-worker heartbeat 4 ##### waits for new entries until Ctrl-C #####
--follow keeps printing new lines until interrupted, and --lines controls how much recent context appears before the live stream starts. Add --no-tail when all stored lines should remain visible in follow mode.
$ sudo journalctl -u queue-worker.service --priority=warning..alert --no-pager Apr 13 13:13:43 server queue-worker[197]: queue backlog above soft limit
The range warning..alert includes priorities 4 through 1 and leaves out notice, info, and debug messages. This is a quick way to surface configuration errors, restart warnings, or dependency failures before reading the full log history.
$ sudo journalctl --list-boots --no-pager IDX BOOT ID FIRST ENTRY LAST ENTRY 0 bfe85af24e244db2b3f98dce23b9ae1d Mon 2026-04-13 13:12:36 UTC Mon 2026-04-13 13:14:08 UTC
When the table includes a -1 entry, open the previous boot for the same service with sudo journalctl -u queue-worker.service -b -1 --no-pager.