Reading systemctl --failed: Investigate Failed Units

systemctl --failed lists systemd units whose state is recorded as failed. It is a useful starting point, but a failed unit does not always mean the machine is currently unavailable. A oneshot task may have failed and left the main application running; an inactive service may be intentional.

Inspect one unit in context

systemctl --failed
systemctl status example.service
journalctl -u example.service -b --no-pager

Replace example.service with the actual unit name. Look at the exit status, recent start attempts, dependencies and journal messages. Check when the failure occurred and whether it matches the user-visible incident.

Find the reason before clearing the state

Common causes include a bad configuration, unavailable dependency, permission error or exhausted resource. Confirm the unit's configuration path and recent changes before editing it. For a network service, also verify whether the process is listening on the expected address and port.

systemctl reset-failed clears systemd's recorded failed state and may reset a start-limit counter; it does not repair the underlying cause. Use it only after the unit has been corrected and you are ready to retry.

Verify the service users need

After a targeted change, start or restart the unit according to the service's operational procedure. Check its status and logs, then test the application from the normal client path. If the unit is intentionally disabled or a timer ran once and failed, record the owner and expected behavior so the alert is meaningful next time.

Use the failed-unit list as an index into evidence, not as a command to restart everything in the output.