home assistant automation continue on error: continue_on_error: true is a per-step option that lets one optional action fail while later steps run; the error stays in the trace and logs.
What the option changes
By default, a Home Assistant automation or script stops when a step fails: the run is marked as failed and the error is logged. That suits most sequences but not a harmless step like a notification.
continue_on_error: true sits on a single step. When that step fails, Home Assistant records the error and moves on instead of ending the run. It is not a global setting, conditions do not have it, and the official scripts documentation shows the placement.
- It does not suppress configuration errors such as a broken template; those still fail the run and appear in the trace and logs.
- It is not a try/catch block: no catch branch, no error object, no retry policy.
Target resolution can also go the other way: docs describe cases where an unavailable or unknown target is skipped with a warning, and the next step runs even without the flag. That is not a blanket guarantee about device status: a device or integration can still raise an action error. What counts is what the action reports in its trace, not whether the target looked healthy.
A minimal, safe example
The script below is illustrative syntax, not a live-tested failure injection. Both steps use persistent_notification.create, a built-in action.
sequence:
- alias: "Optional morning notification"
continue_on_error: true
action: persistent_notification.create
data:
title: "Morning check ran"
message: "The optional notification step ran."
- alias: "Diagnostic notification"
action: persistent_notification.create
data:
title: "Morning check finished"
message: "Reached the last step; check the trace for a recorded error."In a real sequence, put the line on the step that can fail at runtime, such as an unreachable notify integration. It demonstrates syntax, not a guarantee that every possible exception is suppressed; because both steps usually succeed, it shows structure rather than proven error handling. In the visual editor, the flag sits in the step's Menu under Continue on error.
What it does not cover
continue_on_error is not the timeout option: waits have their own timeout and continue_on_timeout settings, and continue_on_timeout defaults to true (Wait for a trigger); wait template vs wait for trigger covers which wait to use. A delay is a different symptom: if a pause seems to vanish, the automation mode or a cancelled run is the usual cause (Home Assistant automation delay).
The option does not make an automation correct either: a wrong entity ID, a removed service, or an unrenderable template still moves the problem downstream. Fix the cause in the trace, not around it.
Failure, timeout, and condition cheat sheet
Situation | Default | With | How to confirm |
|---|---|---|---|
Action fails at runtime | Run stops; Stopped on error | Next step runs, run finishes, error recorded | Trace and Step details |
Broken template or configuration | Run fails; the option cannot suppress it | Same | Fix the configuration and re-run |
Target unavailable or unknown | May be skipped with a warning; some actions still error | Applies when that action reports an error | Trace and Step details |
Wait reaches its timeout | The wait's | No change | Check |
Condition is false | Automation-level: the run can stop before the action sequence starts. In a sequence: later steps on that path do not run | No change; conditions lack the option, so it is not a bypass | Trace shows which condition ended the run or path |
Keep safety-dependent steps failing closed
Leave the flag off any step whose failure changes your home in a way you would not accept. A lock, garage door, heater, or valve should stop the sequence and surface the error instead of letting later steps assume success. Stopping surfaces the problem; it does not by itself leave the device in a safe state or confirm the operation, so check the device too.
Mark a step optional only when later steps do not require its success, keep required prerequisites and checks non-optional, and verify the actual outcome rather than assuming success.
How to confirm the run continued
Open Settings > Automations & scenes, select the automation, then open Traces. Compare two signals:
- The run's result. Stopped on error means the failure ended the sequence; a finished run containing a continued action means the flag worked.
- The step itself. Select the failed action and read Step details; the error text explains what happened even though the run continued.
If the trace shows an action ran but nothing changed, check whether the target was unavailable or had no matching entities, then read the log: skipped targets warn, and some integrations log an error when the device does not respond. Use the troubleshooting guide when the trace alone does not explain the outcome.
