In this article
When a later Home Assistant action does not run, the preceding action may have failed and stopped the sequence. But a warning does not always mean the automation stopped: Home Assistant can skip an unavailable target and continue. A script error can also affect the caller differently depending on how the script was started.
The key is to distinguish a failed action, an explicitly continued error, a skipped target, a configuration error, and an error inside a directly invoked or background script.
This is a documentation-based outcome map. No hands-on testing was performed. It does not cover timing, cancellation, trace interpretation, retries, recovery guarantees, integration-specific behavior, or undocumented exception handling.
The baseline: actions run in order
Home Assistant ordinarily runs an automation or script’s actions sequentially, from top to bottom. If an action fails, actions after it do not run by default (Action reference).
For example:
- Turn on a hallway light.
- Send a notification.
- Activate an evening scene.
If step 2 fails, the documented default is that step 3 does not run.
A condition between actions is a separate control-flow case. If the condition is not met, subsequent actions do not run (Action reference). That is not the same as an action error.
The documented outcome map
| Situation | Documented treatment | Do later actions run? |
|---|---|---|
| Ordinary action failure | The action fails | No, by default |
| Error with Continue on error enabled | Home Assistant proceeds to the next action when the option applies | Yes |
| Configuration error such as a broken template | Continue on error does not ignore it | No, under the documented default failure behavior |
| Unavailable or nonexistent target | The target is skipped and a warning is logged | Yes, without Continue on error |
| Directly selected entity does not support the action | The action fails | No, by default |
| Response-returning action has no matching targets | The action fails | No, by default |
| Directly invoked script stops because of an error | The caller waits and stops too | No |
| Script started with Turn on script encounters an error | The error does not affect the caller | Yes; the caller continues |
The action and target outcomes come from the automation editor documentation. The script outcomes come from the script guide. This table is an editorial synthesis, not a formal Home Assistant error taxonomy.
What Continue on error changes
By default, an automation stops when an action fails. To permit the next action to run after an applicable error, open the failing action’s menu and select Continue on error (Automation editor).
Consider this sequence:
- Send a nonessential status notification.
- Turn off downstairs lights.
- Activate the alarm.
If the notification’s failure does not matter to the remaining steps, enabling Continue on error for that action can let steps 2 and 3 run. Home Assistant recommends using the option only when an action’s failure does not matter to the rest of the automation (Automation editor).
This is an action-level option, not a general recovery mechanism. The documentation does not enumerate every runtime error it can cover, and enabling it does not establish retry or recovery behavior.
What the option does not ignore
Continue on error does not ignore errors in an automation’s configuration. The documented example is a broken template (Automation editor).
The option is also unavailable for conditions placed under Then do (Automation editor). If such a condition is not met, later actions do not run. That is condition-based control flow rather than an action failure that this setting can bypass.
A skipped target is not a failed action
An unavailable or nonexistent target does not make the action fail. Home Assistant skips that target, logs a warning, and runs the next action without requiring Continue on error (Automation editor).
That distinction explains how an automation can produce a warning yet still reach later actions. It does not establish the exact warning text or define every result for mixed groups of valid, unavailable, and invalid targets.
Not every target problem receives this warning-only treatment. An action fails when an entity selected directly does not support the requested action (Automation editor). Under the default failure rule, later actions then do not run.
An action that should return response data also fails when none of its targets match (Automation editor). Some actions place returned data in a response variable for use by later steps (Action reference). A no-match failure for such an action is therefore different from skipping an unavailable target.
For either failure case, the supplied documentation does not confirm that Continue on error covers every possible error. It documents the general option but does not provide an exhaustive eligibility list.
Script invocation changes the caller’s outcome
When an automation or another script invokes a script directly, the caller waits for it to finish. If the invoked script stops because of an error, the caller stops too (Script guide).
Turn on script uses a different path: it starts the script in the background, and the caller does not wait. Errors in the started script do not affect the calling automation or script, and this method returns no response (Script guide).
This distinction describes only what happens to the caller. It does not guarantee that the background script succeeds, completes, retries, or recovers.
A compact decision path
When later actions unexpectedly run—or do not—classify the preceding event:
- Unavailable or nonexistent target: skip the target, log a warning, and continue.
- Action failure: stop later actions by default.
- Eligible error with Continue on error enabled: proceed to the next action.
- Configuration error such as a broken template: the option does not ignore it.
- Error in a directly invoked script: the waiting caller stops too.
- Error in a script started with Turn on script: the caller is unaffected, but receives no response.
These distinctions are narrow by design. They explain the outcomes documented by Home Assistant without assuming retries, timing behavior, or integration-specific error handling.
No comments yet