systemd list failed services: a practitioner’s troubleshooting guide

Updated: 2026-05-26T19:03:32+00:00

A midnight alert fires, a checkout API slows down, and the only clue is that a daemon “failed” sometime after a deploy. In that moment, using systemd list failed services is less a command than a triage habit, because it tells you exactly where to look before the incident spreads. Used well, systemd list failed services helps you separate a real outage from a stale unit state, a dependency issue, or a restart loop that already recovered.

This guide shows how systemd list failed services works, how to read the output without overreacting, and how to turn it into a reliable monitoring signal. You will also see which settings matter most, how to avoid false positives, and how to decide when a service failure is actionable versus noise. For broader Linux observability context, you can pair this with Linux server monitoring best practices, server performance monitoring, and how to monitor server performance on Linux.

What Is systemd list failed services

systemd list failed services is the practical act of listing systemd units currently in a failed state so you can inspect and fix them. On most Linux systems, that means using systemctl --failed or systemctl list-units --state=failed, which show units that systemd considers failed right now. Wikipedia provides a broader overview of how this manager handles unit states.

A simple example is a web server that could not bind to port 80 because another process already used it. In that case, the unit appears failed, the journal explains the bind error, and the failure disappears after you resolve the conflict and restart the service.

This differs from generic uptime checks. Uptime monitoring tells you whether a host or endpoint is reachable; systemd list failed services tells you which local service units on that host are in trouble and often why. In practice, you use both: monitoring catches symptoms from the outside, while systemd gives you the inside view.

How systemd list failed services Works

systemd records a unit failure when a service exits non-zero, times out, crashes, or cannot start. That matters because you need a concrete failure state, not a guess, before escalating. If you skip this, you may chase logs for a service that actually recovered.
systemctl --failed queries the manager for units in the failed state. That matters because it gives you a compact list of units that need review. If you skip it, you waste time scanning all units manually.
The output shows the unit name and its state columns. That matters because loaded, active, and failed together tell a better story than a single status flag. If you skip the column reading step, you may misread a transient issue as a live outage.
You inspect one unit with systemctl status name.service. That matters because the status view usually includes the last error message and recent log excerpt. If you skip this, you only know something failed, not why.
You follow with journalctl -u name.service for the full timeline. That matters because many failures happen several lines before the final exit message. If you skip the journal, you often miss the root cause, especially for dependency or permission errors.
You clear the state only after fixing the cause, using systemctl reset-failed when appropriate. That matters because failed state is sticky until reset. If you skip this after repair, dashboards and scripts may continue reporting an old incident.

A realistic example: a payment worker fails after a config change, then retries and succeeds on the second start. Even then, systemd list failed services still shows the failed unit until you inspect it, confirm the cause, and decide whether to reset the state or keep it as evidence for post-incident review.

Features That Matter Most

When teams rely on systemd list failed services, a few features separate useful signal from noisy housekeeping. The right setup also helps teams who already run server CPU monitoring or broader host checks through the Zuzia features page.

Feature	Why It Matters	What to Configure
Failed-state listing	Shows current units needing attention	Use `systemctl --failed` in scripts and triage runbooks
Unit-level status	Reveals last error and exit details	Standardize `systemctl status <unit>` in incident notes
Journal correlation	Shows the event timeline around the failure	Pull `journalctl -u <unit> -b` for the active boot
Exit-code inspection	Helps automation decide if a failure is real	Check command exit status and guard against stale output
Reset behavior	Clears old failures after fix	Use `systemctl reset-failed` only after root cause is addressed
Dependency visibility	Separates root failures from cascading ones	Inspect `systemctl list-dependencies <unit>` when chains fail
Script-friendly output	Supports alerts and automation	Use `--no-pager` and stable parsing rules

A solid production setup typically includes failed-state checks plus journal review, because systemd list failed services alone tells you where to look, not always what to fix. For developers, understanding the MDN documentation on exit codes can help in writing better unit definitions.

Who Should Use This (and Who Shouldn't)

The command systemd list failed services fits teams that need fast, local service triage on Linux hosts. It is especially useful when uptime and monitoring teams want to understand whether a failed check maps to a service crash, a boot-time failure, or an intermittent restart loop.

Platform engineers managing multiple Linux services on shared hosts.
DevOps teams debugging deploy-related outages after config changes.
SREs building alert rules for failed daemons and startup regressions.
MSPs and agencies handling many customer servers with repeatable triage.
Operators who need a local companion to external uptime checks.
Right for you if you need to confirm which unit actually failed.
Right for you if you need a fast first-pass triage command.
Right for you if you maintain runbooks for on-call responders.
Right for you if you want to automate failed-service detection.
Right for you if you already use host metrics, logs, and uptime checks together.
Right for you if you need to verify system health after a reboot.
Right for you if you are auditing service stability over time.
Right for you if you are integrating host-level signals into a central dashboard.

This is NOT the right fit if you only need public website availability checks. This is also NOT the right fit if your environment does not use systemd, such as certain container-only environments or legacy SysVinit systems.

Benefits and Measurable Outcomes

The real value of systemd list failed services is not the command itself. It is the reduction in time wasted on guessing, manual scanning, and unnecessary escalations.

Faster triage: you identify the failing unit in seconds, which shortens first-response time during incidents.
Cleaner escalation: on-call responders get a named service, not a vague “server down” alert.
Better root-cause isolation: a failed mount, socket, or dependency becomes visible before engineers blame the application.
Lower alert noise: stale failures are distinguishable from current outages when you pair the command with journald timestamps.
Improved team coordination: platform, app, and infra teams can reference the same unit name and failure window.
More reliable automation: scripts can poll the failed state and trigger only when a unit is genuinely stuck.
Better incident review: postmortems are easier when the failure history is tied to the unit and boot cycle.

For professionals and businesses in the uptime and monitoring space, this means fewer blind spots between an external check and the internal service state. When you run systemd list failed services, you gain visibility into why a host might be reachable while a critical daemon is already broken.

How to Evaluate and Choose

The best way to evaluate tooling around systemd list failed services is to ask whether it helps you detect, interpret, and act on failures without adding noise. The same logic applies whether you rely on shell scripts, a monitoring agent, or a broader uptime platform.

Criterion	What to Look For	Red Flags
Detection speed	Failed units appear quickly after the state changes	Long delays between failure and visibility
Output stability	Commands return predictable, parseable text	Scripts depend on brittle human-readable formatting
Exit-code support	Automation can branch on success or failure	The tool always returns success, even on errors
Journal access	You can jump from failed state to logs easily	Log lookup is manual and inconsistent
Dependency awareness	Cascading failures are visible	Every failure looks like an isolated app crash
Reset control	You can clear stale states deliberately	Failed states linger after recovery
Alert routing	Failures can reach the right team fast	Everyone gets the same generic alert

These criteria matter whether you are using systemctl, a local agent, or a monitoring suite that polls host health. They also line up with common uptime checks such as HTTP, ping, port, SSL, and DNS monitoring, because most real incidents involve more than one signal. For those working with network-dependent services, reviewing RFC 1035 for DNS or related standards helps in understanding why a service might fail to resolve dependencies.

Recommended Configuration

A production-friendly setup keeps systemd list failed services useful without turning every transient hiccup into an incident. The settings below are practical defaults, not universal rules.

Setting	Recommended Value	Why
Check interval	30–60 seconds for critical services	Catches persistent failures without overpolling
Retry window	2–3 consecutive checks	Filters transient restarts and short-lived blips
Alert threshold	Alert only after the failure persists	Prevents noise from self-healing services
Log scope	Current boot plus recent unit logs	Focuses review on the relevant incident window
Reset policy	Manual reset after root cause confirmation	Preserves evidence until the issue is understood

A solid production setup typically includes one script or agent that polls the failed state, one log review step, and one alert rule that waits for persistence. If you already use how Zuzia works or pricing and plan details to manage monitoring coverage, this is the sort of host-level signal that complements external uptime checks.

Reliability, Verification, and False Positives

False positives usually come from a few predictable sources. Services can fail once during boot and recover, dependencies can be missing temporarily, or a unit can enter failed state after a timeout. The best prevention is layered verification. Start with systemd list failed services, confirm the unit with systemctl status, then read journalctl -u <unit> for the actual error line.

Multi-source checks reduce noise further. For example, if a database worker is failed but the process restarted, check whether port monitoring still sees the socket. This is where systemd list failed services becomes one signal among several, not the only source of truth.

Retry logic should be conservative. A single failed poll is often not enough for incident escalation, especially after deploys or reboots. Use a short retry window, and only escalate when the same unit remains failed across multiple checks. If your org already routes notifications through tools like the Zuzia homepage or reviews and customer feedback, align failed-service alerts with the same severity model.

Implementation Checklist

Planning: Identify which services are critical enough to alert on immediately.
Planning: Decide which failures should be informational only.
Planning: Map each unit to an owner or responder group.
Setup: Confirm the command works on every target host.
Setup: Standardize systemctl status <unit> and journalctl -u <unit> in the runbook.
Setup: Decide whether alerts should trigger on one failed poll or multiple.
Verification: Test a non-production unit failure and confirm the alert path.
Verification: Check that stale failed states are cleared after remediation.
Verification: Validate that logs, alerts, and unit names all match.
Ongoing: Review repeated failures weekly to spot brittle services.
Ongoing: Revisit thresholds after deploys, upgrades, or boot changes.
Ongoing: Audit scripts for brittle parsing after systemd or distro updates.

Common Mistakes and How to Fix Them

Mistake: Treating every failed unit as an outage.
Consequence: On-call noise rises, and teams stop trusting alerts.
Fix: Add retries and require persistence before escalation.

Mistake: Reading only the failed-state list and skipping logs.
Consequence: Engineers fix symptoms instead of root cause.
Fix: Make log inspection part of the standard workflow after running systemd list failed services.

Mistake: Forgetting that failed state remains after the service is fixed.
Consequence: Dashboards keep showing an old incident.
Fix: Reset failure state only after confirmation with systemctl reset-failed.

Mistake: Monitoring the host but not the service dependency chain.
Consequence: A mount or database dependency causes repeated confusion.
Fix: Check dependencies when the direct service fix does not hold.

Mistake: Using a single poll as the final truth.
Consequence: Brief startup races become false incidents.
Fix: Require repeated confirmation before paging humans.

Best Practices

Use systemd list failed services as the first triage step, not the last one.
Pair failed-state checks with the service journal every time.
Treat dependency failures differently from application crashes.
Keep a clear owner for every critical unit.
Separate maintenance windows from genuine incident alerts.
Test service-failure alerts during non-peak hours before relying on them.

A useful mini workflow for a common failure looks like this:

Run the command to list failed units.
Inspect the specific unit with systemctl status <unit>.
Read journalctl -u <unit> -b.
Check dependencies and recent changes.
Fix the root cause, then clear the stale state if needed.

FAQ

What command performs systemd list failed services?

The shortest command is systemctl --failed. That command shows units currently in the failed state. systemctl list-units --state=failed returns equivalent information and is the longer form of the same query.

How do I check whether one service failed?

Use systemctl is-failed <service-name>. It returns the failed state for one unit and works well in scripts. That makes it useful when you want to test systemd list failed services behavior for a specific daemon.

Why does a service stay failed after I fixed it?

Because systemd keeps the failed state until you reset it or the unit is restarted cleanly. That is normal. If the service is healthy again, use systemctl reset-failed only after confirming the root cause is gone.

What is the best way to troubleshoot a failed service?

Start with systemctl status, then read the unit journal with journalctl -u <unit>. That sequence usually shows the actual error, such as a missing file or a port conflict. It is the fastest way to turn systemd list failed services into an actionable diagnosis.

Can I automate alerts from failed systemd units?

Yes, and that is a common monitoring pattern. Poll the failed units, confirm the same unit across multiple checks, and send an alert only when the failure persists. This reduces noise from startup races and brief recovery loops.

How does this relate to uptime monitoring?

It complements it by revealing local service state, not just network reachability. A host can answer ping and still have a failed application unit. That is why uptime teams often pair external checks with systemd list failed services, response-time checks, and port monitoring.

Conclusion

The practical value of systemd list failed services is speed, clarity, and better triage. It gives you a precise starting point, it narrows the log search, and it helps you decide whether the incident is local, dependency-driven, or already recovered.

Three takeaways matter most. First, always pair the failed-state check with systemctl status and the journal. Second, use retries and confirmation windows so transient failures do not wake people unnecessarily. Third, treat failed units as one signal in a larger uptime workflow, not the whole truth. If you are looking for a reliable uptime and monitoring solution, visit zuzia.app to learn more. Using systemd list failed services effectively ensures your internal service health matches your external uptime promises.