How to view service logs using journalctl

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.

Steps to view service logs using journalctl:

  1. Show the newest entries for the target service first.
    $ 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.

  2. Limit the results to the current boot or the incident window when older restarts add noise.
    $ 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.

  3. Follow new service log entries live while reproducing the issue.
    $ 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.

  4. Reduce the output to warning-level events and above when triaging failures faster matters more than seeing every line.
    $ 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.

  5. List recorded boots before opening logs from an earlier service failure.
    $ 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.