systemctl list failed services: a practical operator's guide

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

A pager goes off at 2:14 a.m., but the server still answers pings and the website looks fine. The real issue is hiding in plain sight: systemctl list failed services shows a unit that crashed three times, never recovered, and left no customer-facing symptom yet. That is exactly why operators use systemctl list failed services before they start guessing.

In uptime and monitoring work, this command is not just a troubleshooting shortcut. It is a fast way to separate noisy symptoms from real service failures, confirm whether a restart loop is happening, and decide whether the problem belongs in the application, the host, or the alerting policy. In the sections below, you will see how the command works, which settings matter most, how to avoid false positives, and how to turn failed-unit checks into a reliable monitoring signal. For context on broader server health practices, see server performance monitoring best practices, Linux server monitoring best practices, and how to monitor server performance on Linux.

What Is systemd failed-unit listing

systemctl list failed services is the common operator shorthand for listing systemd units that are currently in a failed state. In practice, the canonical commands are systemctl --failed, systemctl list-units --failed, or systemctl list-units --state=failed. [1][2][3]

A concrete example helps. If nginx.service fails because its port is already in use, systemctl --failed will surface that unit immediately, even if the host is otherwise healthy. If you already know the unit name, systemctl is-failed nginx.service is faster for scripting and returns an exit code that automation can use. [1][2][3]

This differs from generic health monitoring. A ping monitor can confirm reachability, and an HTTP check can confirm one endpoint, but neither tells you whether a background daemon has entered a failed state. For deeper service triage, systemctl status, journalctl -u, and dependency inspection usually follow the failed-unit list. [7][8]

In practice, systemctl list failed services is the first pass in a failure workflow. It is the command you run when the server is “up” but something important is clearly not behaving. [1][2][8]

How systemd failed-unit listing Works

systemd records the failure state. When a service exits with an error or a startup dependency fails, systemd marks the unit failed. That matters because the failed state becomes queryable from the manager itself, not just from logs. If you skip this mental model, you may keep searching only in application logs and miss the system-level signal. [1][2]
You query the manager for failed units. systemctl --failed or systemctl list-units --state=failed asks systemd for units in memory with a failed state. That matters because it gives you a consistent inventory rather than a one-off log scrape. If you skip the query and rely on memory, recurring failures are easy to miss. [1][2][3]
You narrow the scope when needed. systemctl list-units --type=service --state=failed filters to services only. This matters in mixed environments where mounts, sockets, timers, or other units can fail as well. If you skip the filter, you may investigate the wrong unit class first. [7][9]
You inspect one unit in detail. systemctl status name.service shows the active state, recent logs, and exit hints. This matters because the failed state tells you that something failed, while status tells you what failed. If you skip this step, remediation turns into guesswork. [4][8]
You read the journal for the full error path. journalctl -u name.service gives the full timeline, not just the last few lines. This matters for crash loops and timeouts, where the decisive clue may be earlier than the current status output. If you skip the journal, you can easily fix the symptom instead of the cause. [8]
You clear the state only after verification. systemctl reset-failed removes the failed marker, but it does not repair the underlying problem. That matters because resetting too early can hide recurrence and weaken alerting. If you skip verification, a failing unit can look “clean” while still broken. [2][7]

A realistic scenario: a nightly batch worker exits because a credential expired. systemctl list failed services reveals the unit, systemctl status shows exit code clues, and journalctl confirms the auth error. The fix is then operational, not speculative. [2][8]

Features That Matter Most

The value of systemctl list failed services depends on how you use it inside an uptime workflow, not just on the command itself. For operators, the important features are the ones that reduce time to diagnosis and lower alert noise. [1][2][8]

Feature	Why It Matters	What to Configure
`--failed` listing	Gives a fast inventory of failed units	Use it in ad hoc checks and automation jobs [1][2][3]
`--state=failed` filtering	Lets you scope output to the failure state only	Combine with `--type=service` when you only care about daemons [1][2][7]
`is-failed` checks	Supports scripting and exit-code based monitoring	Use for one known unit in cron, CI, or watchdog scripts [1][2][3]
`systemctl status` drill-down	Shows recent logs and state context	Always pair it with failed-unit output during triage [4][8]
`journalctl -u` correlation	Provides the detailed event history	Restrict by boot or time window when the failure is intermittent [8]
`reset-failed` control	Clears stale failure markers after remediation	Use only after root cause is fixed and verified [2][7]
`list-unit-files` context	Helps separate enabled services from transient issues	Review enabled services that should never fail silently [9]

For uptime teams, the strongest feature is the combination of list, inspect, and verify. That sequence prevents the classic error of treating a state flag as a root cause. For related Linux service visibility, see server CPU monitoring and Linux uptime monitor guidance.

Who Should Use This and Who Shouldn't

systemctl list failed services is best for teams that already care about host-level reliability and service recovery. It works especially well where a failed daemon is more actionable than a broad infrastructure alarm. [1][2][8]

SREs who need a first-pass inventory of failed daemons during an incident.
DevOps engineers who want a shell-friendly signal for restart loops or crash-on-start behavior.
Linux administrators who need to confirm whether a service failure is isolated or repeated.
Monitoring engineers who want to enrich alerts with exact failed-unit names.
SaaS operators who run multiple systemd-managed services on the same host.
Right for you if you need to know which Linux services failed after a deployment.
Right for you if you want an exit-code friendly check for automation.
Right for you if you already use systemctl status and journalctl in your workflow.
Right for you if your alerting should distinguish service failure from host outage.
Right for you if you manage systemd-based servers at scale.
Right for you if you want to reduce blind spots between application logs and host state.

This is not the right fit if your services are not managed by systemd, or if your environment is almost entirely container orchestrated without host-unit visibility. It is also not enough on its own if you need application-level health, transaction success, or synthetic website checks. [7][8]

Benefits and Measurable Outcomes

The practical value of systemctl list failed services is that it shortens the gap between “something is wrong” and “here is the failing unit.” In uptime work, that gap is often where the most expensive minutes are lost. [1][2][8]

Faster triage: you move from vague symptoms to a named unit in seconds, which shortens incident response for on-call teams.
Lower alert ambiguity: the failed-unit list separates service failure from packet loss, DNS issues, or partial application outages.
Better post-incident review: you can identify recurring units and correlate them with deploys, reboots, or dependency failures.
Cleaner escalation: platform teams can route a specific failed service to the right owner instead of opening a broad infrastructure ticket.
Improved uptime reporting: failed-unit events give more precise downtime context for professionals and businesses in the uptime and monitoring space.
More reliable automation: exit codes from systemctl is-failed let scripts make deterministic decisions instead of parsing human-oriented output.
Better alert enrichment: service names, timestamps, and status clues help operators understand what failed before they open logs.

In production monitoring, these outcomes matter because they reduce mean time to diagnosis, not just mean time to recovery. A failed database-sidecar unit might never trip an HTTP check, yet it still matters to the business. That is where systemctl list failed services earns its place in the stack. [2][8]

How to Evaluate and Choose

The right workflow depends on whether you are doing manual troubleshooting, scheduled checks, or alert-driven automation. Competitor pages often focus on broad uptime monitoring, but the operational gap is how service-state signals fit into the rest of the stack. For broader monitoring context, review how Zuzia works, the features overview, and the pricing section. [1][2][7]

Criterion	What to Look For	Red Flags
Detection scope	Can you detect only services, or all failed units?	A check that misses sockets, timers, or mounts when you need them [1][2][7]
Scriptability	Can the command return a clean exit code?	Output-only workflows that are hard to automate reliably [1][2][3]
Granularity	Can you inspect one unit without scanning everything?	Needing a full-text grep for every incident [1][2]
Correlation	Can you link the failure to logs and boot context?	A tool that lists failures but cannot explain them [8]
Recovery workflow	Can you safely reset state after verification?	Resetting blindly and hiding recurring failure patterns [2][7]
Operational fit	Does it complement uptime checks, SSL checks, and port checks?	Using host-state checks as a substitute for external availability monitoring

Use these criteria to decide whether you need a simple shell check, a dashboard view, or a broader monitoring platform. In most production environments, the answer is “all three,” because each layer catches a different failure class.

Recommended Configuration

A solid production setup typically includes a failed-unit check, a status check, a log lookup, and a separate external uptime signal. That combination is more useful than any single command because it distinguishes internal service failure from user-visible outage. [1][2][8]

Setting	Recommended Value	Why
Service filter	`--type=service`	Keeps the output focused on daemon failures [7][9]
State filter	`--state=failed`	Avoids mixing failed units with inactive ones [1][2]
Known-unit probe	`systemctl is-failed NAME`	Makes automation simpler and easier to alert on [1][2][3]
Investigation pair	`systemctl status NAME` + `journalctl -u NAME`	Gives both summary and root-cause context [4][8]
Reset policy	Only after fix verification	Prevents stale-looking systems and missed recurrence [2][7]

A strong production workflow usually includes:

a host-side unit check,
an external website or API check,
a log review step,
a timed retry policy,
and a maintenance-window rule for planned restarts.

If your environment also tracks HTTP, SSL, or port health, keep those checks separate from the systemd failed-unit signal. They answer different questions, and mixing them usually makes alerting worse rather than better.

Reliability, Verification, and False Positives

False positives usually come from stale failed states, transient startup races, dependency timing, or services that are expected to fail during maintenance. They can also come from checking too early after boot, before all dependencies are ready. [2][7][8]

Prevention starts with timing. If you query systemctl list failed services too soon after a reboot or deploy, you may catch normal transient failures that clear a few seconds later.

Multi-source checks work better than a single signal. Pair the failed-unit list with systemctl status, journalctl -u, and an external check such as HTTP or TCP port validation. That gives you host state, log evidence, and user-facing reachability in one incident view. [8]

Retry logic should be intentional. For example, a failed service that restarts automatically may deserve a short retry window before paging, while a critical control-plane service may warrant immediate escalation. The alert threshold should reflect how often a service is expected to flap, not just whether it failed once.

Maintenance windows matter as well. If a service is supposed to restart during a deploy, suppressing alerts for that period is often better than generating noisy incidents. For teams that already coordinate maintenance windows in a monitoring platform, the failed-unit signal can still be recorded without paging the on-call engineer.

Implementation Checklist

Identify the systemd services that must never fail silently.
Decide whether you need all failed units or only services.
Define which checks are manual, scripted, and alerting-only.
Add a verification step with systemctl status for each critical unit.
Add a journal lookup step with journalctl -u for root-cause review.
Decide when reset-failed is allowed and who can run it.
Set retry rules for flapping services before any pager notification.
Document maintenance windows for planned restarts and deploys.
Correlate failed-unit alerts with external uptime checks.
Review repeated failures weekly and track recurring service names.
Confirm that service owners know how to interpret the failure output.
Test the workflow after a controlled service stop and recovery.

Common Mistakes and How to Fix Them

Mistake: Treating systemctl list failed services as the root cause.

Consequence: Operators restart the service without fixing the real issue, so the failure returns.

Fix: Use systemctl status and journalctl -u before any remediation. [4][8]
Mistake: Clearing failed state immediately with reset-failed.

Consequence: The host looks healthy while the underlying defect remains.

Fix: Reset only after a successful fix and a restart confirmation. [2][7]
Mistake: Alerting on every single transient failure.

Consequence: On-call teams get noisy pages during boot storms or brief dependency delays.

Fix: Add retries and maintenance-window suppression.
Mistake: Checking only external uptime and ignoring host service state.

Consequence: A local daemon can fail while the site still appears partially alive.

Fix: Pair external checks with systemctl list failed services and unit logs.
Mistake: Using the wrong unit class.

Consequence: You miss sockets, timers, or mount failures that affect the service indirectly.

Fix: Decide whether your operational question is service-only or all-unit visibility. [1][2][7]

Best Practices

Run systemctl list failed services as part of first-response triage on Linux hosts.
Keep service-state alerts separate from website and API uptime alerts.
Use systemctl is-failed for known units in automation.
Prefer systemctl status before restart attempts.
Read journalctl -u with a tight time window when failures repeat.
Build retry logic for startup races and flapping dependencies.
Record maintenance windows for planned restarts.
Review recurring failures by service name, not by incident number.

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

Run systemctl --failed.
Inspect the affected unit with systemctl status NAME.
Review the logs with journalctl -u NAME --since "1 hour ago".
Fix the root cause and restart the service.
Verify the unit stays active before resetting failure state.

That sequence is simple, but it is also what separates experienced operators from button-pushers.

FAQ

What does systemctl list failed services show?

It shows systemd units currently marked as failed. The most common forms are systemctl --failed, systemctl list-units --failed, and systemctl list-units --state=failed. [1][2][3]

The output is useful because it turns hidden service failures into a short, explicit list. You still need systemctl status and logs to understand why each unit failed. [4][8]

Is systemctl --failed the same as systemctl list failed services?

Yes, in modern systemd usage they are functionally equivalent for listing failed units. systemctl --failed is the shorter form, while systemctl list-units --state=failed is the more explicit form. [2][3][5]

Use the shorter form for quick operator checks and the explicit form when writing scripts or documentation. That keeps the intent obvious for anyone reading the command later. [2][3]

How do I check one specific service?

Use systemctl is-failed name.service or systemctl status name.service. The first is best for exit-code based checks, while the second is better for human troubleshooting. [1][2][3][8]

This is the practical way to make systemctl list failed services part of automation. You can gate a script on the exit code and then fall back to logs only when needed. [1][2]

Why does a service show failed even after I fixed it?

The failed state can remain until you clear it with systemctl reset-failed, but only after the underlying issue is fixed. If the unit fails again immediately, the state is telling you the fix did not hold. [2][7]

This is common after manual restarts, temporary dependency problems, or repeated crash loops. Treat the failed marker as evidence, not as the cause itself. [2][8]

Can I use systemctl list failed services in monitoring?

Yes, and it is especially useful for internal service-state monitoring on Linux hosts. It works well when combined with external uptime checks, SSL checks, port checks, and log-based alerts. [1][2][8]

For professionals and businesses in the uptime and monitoring space, that layered approach catches failures that a website-only monitor would miss. It also helps reduce false confidence when the host is alive but a critical daemon is not. [8]

What should I do first after a failed service appears?

Check systemctl status and then read the service journal. That usually tells you whether the problem is a bad config, missing dependency, permission issue, or port conflict. [4][8]

After that, fix the root cause, restart the service, and verify it remains healthy before resetting the failure state. That sequence is the safest way to handle systemctl list failed services in production. [2][7]

Conclusion

The most useful takeaway is that systemctl list failed services is a state signal, not a diagnosis. It tells you where to look first, then systemctl status and journalctl -u tell you why the failure happened. [1][2][8]

A second takeaway is that host-level failure checks and external uptime checks solve different problems. A service can fail without a total outage, and a website can be slow while the underlying daemon still looks fine. That is why layered monitoring matters more than any single command.

A third takeaway is operational discipline: do not reset failed state until the cause is fixed, and do not page on every transient blip. Used well, systemctl list failed services becomes part of a calm, repeatable incident workflow rather than a noisy one-off command.

If you are looking for a reliable uptime and monitoring solution, visit zuzia.app to learn more.