systemctl --failed: Find Broken Units After Boot
systemctl --failed lists all units currently in the failed state, the fastest way to spot a service that did not come up on a runner.
A freshly provisioned runner can boot green yet have Docker or a database unit that crashed on start. systemctl --failed surfaces them in one line each instead of checking units one by one.
What it does
systemctl --failed (shorthand for list-units --state=failed) shows units that entered the failed state, with their load, active, and sub states. After you fix the cause, systemctl reset-failed <unit> clears the failed flag so the unit can be started cleanly again.
Common usage
systemctl --failed --no-pager
systemctl list-units --type=service --state=running --no-pager
systemctl reset-failed docker # clear the failed flag before retrying startOptions
| Flag / subcommand | What it does |
|---|---|
| --failed | Show only units in the failed state |
| list-units --state=running | Show only currently running units |
| --type=service | Restrict to service units |
| reset-failed [unit] | Clear the failed state of a unit (or all) |
| --no-pager | Do not invoke the pager |
Common errors in CI
An empty table under the header means nothing is failed, which is the healthy case. A unit shown as "failed" with sub state "exit-code" means the process exited non-zero; pair this with journalctl -u <unit> to read why. If systemctl start keeps reporting "Start request repeated too quickly", the unit hit its restart limit; run systemctl reset-failed <unit> first.