journalctl Time Ranges That Save Time
Reduce a large systemd journal to the service, boot, time window, and priority that matter to an incident.

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.
