Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Start with the exact unit and the time the problem occurred, then read the nearby journal entries in sequence. For a service error in the current boot, run:
journalctl -u example.service -b --since "30 minutes ago" --no-pagerReplace example.service with the unit’s actual name and adjust the time window. The unit filter shows service records and related systemd manager messages; checking the surrounding entries helps distinguish an application failure from systemd’s report of that failure.
Confirm the unit and its current state
First identify the precise unit name, including its suffix where applicable. Then check its state with the service-management tools available on your system: a unit that is failed, repeatedly restarting, inactive, or active calls for different investigation paths. Journal output records events, but it does not replace checking the unit’s current state or configuration. The systemd debugging guide provides additional troubleshooting context.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteFilter journal entries to the incident
Use -u for the unit and bound the search to the likely incident interval. For example, to inspect a specific illustrative time range:
#1 Best Overall
journalctl -u example.service --since "2026-10-04 11:30:00" --until "2026-10-04 12:00:00"The dates above are an example, not a report of an actual incident. --since and --until accept date/time strings and relative times. See the systemd 255 journalctl manual for the documented options; installed systemd versions can differ, so check journalctl --help or your distribution’s manual if an option behaves differently.
Select the right boot
The default command includes accessible entries across the available journal. Add -b to limit output to the current boot; use -b -1 for the previous boot, or list available boots first:
journalctl --list-boots
journalctl -u example.service -b -1The boot selector can also take a boot ID or relative offset. Prior-boot records are only available if they were retained. A missing entry after reboot is therefore not proof that the service did not fail.
Follow the sequence, not just an error line
Read in time order and look for the earliest relevant failure, along with what happened immediately before it. An application may log a specific cause; systemd may then report that a process exited, a start operation failed, or the unit entered a failed state. Those manager messages describe what systemd observed, but a single line does not necessarily establish why the application failed.
Use a severity filter to locate likely candidates, then widen the view to restore context. These commands offer different views of the same investigation:
| Command | What it changes | When it helps |
|---|---|---|
journalctl -u example.service -b -p err |
Shows error priority and more important priorities for the unit in the current boot. | Quickly locate serious messages; inspect a wider, unfiltered interval if the explanation is missing. |
journalctl -u example.service -b -o short-iso |
Uses ISO-style timestamps. | Compare chronology across nearby records. |
journalctl -u example.service -b -n 100 --no-pager |
Limits output to the most recent 100 entries and disables the pager. | Get a bounded text view directly in the terminal. |
journalctl -f -u example.service |
Follows new entries for the unit. | Watch records arrive while reproducing or observing a problem. |
Priority filtering is a navigation aid, not a complete diagnosis: lower-priority records can contain the lead-up or the application’s more specific explanation. Likewise, a pager may truncate long lines to the screen width. Use horizontal scrolling or --no-pager when you need to inspect the full text. Output modes such as short-full can also help when clearer timestamps matter.
Rank #4
Check whether the relevant records are available
Journal access depends on permissions. Root and members of certain groups can read all journal files; a regular user may see only entries it can access, or warnings about inaccessible journals. Missing records can also result from storage configuration: journald may use volatile storage or persistent storage, and retention affects how far back you can search. The systemd 252 journald.conf manual describes storage settings and journalctl --flush, which moves volatile data to persistent storage under documented conditions.
Expand the search only when the evidence calls for it
Inspect the whole system or kernel
If the service records suggest a system-level dependency, --system selects system services and kernel messages. To focus on kernel messages, use -k; it implies the current boot. Kernel output can add context, but it is not a substitute for the service-unit view.
Best Value
Inspect a user service
For a service belonging to the current user, --user selects that user’s service messages. The manual notes persistence caveats for user journals, so availability may differ from system-service records.
Look for a crash dump
If the journal indicates a core dump, coredumpctl is the related systemd utility for acquiring and processing core dumps. What to do next depends on the application, available debugging tools, and symbols. The systemd 250 coredumpctl manual documents the utility.
Keep filters and shared output in perspective
- With no filters,
journalctlprints accessible collected entries oldest first. - Different field matches are combined as AND; repeated matches for the same field are alternatives by default.
- Do not use
-xwhen attaching output to a bug report. The manual advises against it because explanatory catalog text is intended to add context for interactive reading.
Once you have the relevant sequence, compare it with the unit’s state and inspect likely causes such as configuration, dependencies, permissions, and application-specific diagnostics. The journal is a record of events; establishing a cause may require evidence from those other checks.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
