Linux & Systems

journalctl Time Ranges That Save Time

Reduce a large systemd journal to the service, boot, time window, and priority that matter to an incident.

2 min read
#journalctl#systemd#logs#linux

A forest fading into layers of cool mist

Photo: Unsplash.

journalctl -u app.service is a good start, but on a busy host it can still return days of unrelated history. A small time window usually produces a better first read.

For an incident known to have happened between 13:40 and 14:05:

journalctl -u app.service \
  --since '2023-12-07 13:40:00' \
  --until '2023-12-07 14:05:00'

For a quick recent view:

journalctl -u app.service --since '30 minutes ago'

Include ISO-style timestamps and avoid opening a pager when collecting output for a ticket:

journalctl -u app.service \
  --since '30 minutes ago' \
  --output short-iso-precise \
  --no-pager

Boot boundaries are equally useful. -b selects the current boot, while -b -1 selects the previous one:

journalctl -u app.service -b -1

To focus on warnings and more severe messages:

journalctl -u app.service -p warning --since today

Do not begin by filtering too aggressively. An application’s failure may be preceded by a kernel, network, mount, or dependency message outside that unit. Start with the service, then widen the same time window if the cause remains invisible:

journalctl --since '2023-12-07 13:40' --until '2023-12-07 14:05'

For a live reproduction, add --follow, but save the bounded historical query first. A precise window is easier to share and compare than a terminal that has been scrolling for ten minutes.

Reference