Write down the incident before searching
Record the visible symptom, approximate time, timezone and whether it began after a restart, update or device connection. If you can reproduce it safely, note the time of one deliberate attempt. Do not repeatedly perform a destructive operation just to create more log entries. A narrow question gives the output something to confirm or challenge.
The journal collects messages from several sources, including the kernel and system services. Some desktop applications keep separate logs or send little useful detail to the journal. Therefore no matching entry can mean the wrong source or filter, not that the symptom did not happen. Treat this as one evidence source alongside an application's own documentation.
Begin with a bounded view of this boot
Run journalctl -b -n 50 --no-pager. It asks for the last fifty accessible entries from the current boot and prints them directly. Run journalctl --list-boots to see the boots represented in the retained journal. If a previous boot is listed, journalctl -b -1 -n 50 --no-pager selects its recent entries.
Your ordinary account sees only entries it is permitted to read. System-wide access depends on distribution policy, privileges and group membership. A permission notice or incomplete view is not a reason to make log directories writable. On a managed machine, ask its administrator for the relevant excerpt or approved read access.
journalctl -b -n 50 --no-pagerKeep a service name attached to its evidence
For a service-related symptom, systemctl --failed provides a starting list of failed units that the system manager knows about. It is a status snapshot rather than a complete history. An empty list does not establish that every application worked, and an unrelated failed unit does not automatically explain your symptom.
Use the actual unit name from the machine when filtering its journal. For example, journalctl -b -u example.service --no-pager uses example.service as a placeholder, not a real diagnosis. A per-user service belongs to a separate manager: systemctl --user --failed inspects that manager, and journalctl --user -b -u example.service queries the corresponding user context where its journal is available.
Compare the same time window in the same timezone
Timestamps become misleading when a report uses local time and another system uses UTC. The example below specifies UTC in both bounds and displays results in UTC. Its date and interval are invented practice inputs, so replace them with your actual incident time. Using -b also limits it to the current boot; remove that constraint only when searching a retained older interval intentionally.
The Unix timestamp converter helps when another tool supplies epoch time. Confirm the unit before comparing it: seconds and milliseconds differ by a factor of one thousand. For reference, 1700000000 seconds corresponds to 2023-11-14 22:13:20 UTC. A correct conversion cannot repair an inaccurate machine clock, so retain the original value and its stated timezone or unit with your notes.
journalctl -b --since "2026-11-02 09:00:00 UTC" --until "2026-11-02 09:10:00 UTC" --utc --no-pagerUse priority to narrow the view, then restore context
journalctl -b -p warning --no-pager includes warnings and more severe priorities; it is not an exact warning-only selection. That can reduce noise, but it also hides informational events that explain the sequence. Once you find a relevant time, return to a narrow unfiltered time window around it.
Priority and message text are supplied as part of a log entry; the journal also attaches metadata such as process, user and boot identifiers. These fields help connect messages to a component. They do not turn a frightening phrase into a proven root cause. Compare the component, time, preceding events and reported outcome before deciding what to investigate next.
Understand why older history might be absent
Journal storage can be persistent on disk or volatile under /run, depending on configuration and available storage. Retention limits can remove old data. Consequently, an earlier restart may not appear in --list-boots, and an old time filter may return nothing even with correct syntax. Check the available history before assuming the command is broken.
This reading workflow does not require changing retention or deleting logs. Avoid vacuum and rotation commands while gathering evidence you may still need. If future history must survive restarts, plan storage and retention separately using your installed journald configuration documentation. That change affects later collection; it cannot recreate records already lost.
Share a small, useful excerpt
Include the symptom, Ubuntu version, relevant service or application version, boot context, exact query and timezone. Share the few lines surrounding the event, with enough preceding context to show what led up to it. If using journalctl -f to watch new entries, Ctrl+C ends that viewer; it does not stop the service being observed.
Read an excerpt before posting it. Logs may contain usernames, hostnames, private paths, device identifiers, email addresses, URLs or credentials accidentally printed by an application. Redact sensitive values consistently while preserving timestamps and the relationship between messages. Send the excerpt through the support channel requested by the project, and avoid uploading an entire journal just to ask about one line.
Sources & further reading
Documentation reviewed .
systemd — journalctl ↗systemd — systemd-journald.service ↗systemd — systemctl ↗systemd — systemd.time timestamp formats ↗systemd — Journal fields and metadata ↗systemd — journald.conf storage and retention ↗This guide is based on the sources linked above, with original explanations and examples. Software interfaces and service features can change. A documentation-based guide is not a hands-on product review. Read our editorial policy or report a correction.