Home Assistant Automation Modes: Which Should You Use?

Researched from current Home Assistant documentation and Core 2026.10.3 source on October 24, 2026. The two-press timeline is a calculated example, not a measured Tara installation. No physical device or live Home Assistant installation was tested. Menu labels can vary by installed version. The cover is an AI-generated editorial illustration.

Choose what the second request should do

Home Assistant automation modes answer one question: what should happen if this automation starts again while its previous run is still busy? Start with single, the default. Change it only when you can say why a valid second request should replace, wait behind, or overlap the first.

A trigger starts a routine; an action does something; a run is one trip through its steps. A delay or wait keeps that run busy. For example, “show a reminder after twenty seconds” is still running throughout those twenty seconds, even though nothing visible is happening yet.

Use the decision table, then rehearse with a helper—a software control inside Home Assistant. This needs an administrator account and the built-in Button and Persistent Notification features. You do not need hardware, custom integrations, a phone notification service or a paid subscription. If the real problem is one button producing two unwanted events, start with diagnosing duplicate automation runs; choosing a mode does not repair the source of those events.

1. Decide whether to skip, replace, queue or overlap

Swipe sideways to read all columns.

The official mode reference defines these four behaviors. They apply to the automation as a whole, including its different triggers. Parallel does not create a separate queue or overlap limit for each trigger or room.

Write a sentence before touching the settings: “If I press again during the wait, I want…” If that sentence is unclear, keep the current routine and use the practice example to decide.

2. Make a harmless practice automation

1. Open Settings → Devices & services → Helpers → Create helper. Choose Button and name it Mode practice. Keep it separate from existing device routines.
2. Check the new helper’s entity ID in its settings. An entity ID is its internal name; the example uses input_button.mode_practice. Replace that name in the code if yours differs.
3. Under Settings → Automations & scenes, create a new automation from scratch. In its menu, choose Edit in YAML. YAML is Home Assistant’s text configuration format.
4. Paste the complete automation below and save. This goes in one automation’s editor, not in configuration.yaml. Confirm that the new automation is enabled.

Swipe long code lines sideways.

alias: Mode practice - delayed notice
description: A software-only exercise; no device commands.
triggers:
  - trigger: state
    entity_id: input_button.mode_practice
conditions: []
actions:
  - delay: "00:00:20"
  - action: persistent_notification.create
    data:
      title: "Mode practice finished"
      message: >-
        Button timestamp: {{ trigger.to_state.state }}.
        This run finished at {{ now().strftime('%H:%M:%S') }}.
mode: single

The Button helper records a timestamp each time you press it. The notification reads the timestamp from that run’s trigger data, so a queued run can still identify its original press. It does not read the button’s latest timestamp after waiting. The button timestamp includes its date and time zone; the finish time uses Home Assistant’s local clock.

Persistent notifications appear inside Home Assistant and remain until dismissed. The example deliberately leaves out notification_id; reusing one ID would replace an earlier notice and make two completed runs look like one.

3. Press twice and compare the results

Open the helper’s control from its entity details, or add it to an Entities card on a practice dashboard. Press once, wait about five seconds, then press again. Wait at least forty-five seconds before changing anything. Open Home Assistant’s notifications and the practice automation’s Traces, which show the steps of each run.

Repeat with each mode. Wait until the prior exercise is finished, dismiss only its practice notices, then change the mode and save. In the current editor, use Menu → Change mode. In YAML, replace the final mode: single line. For Queued and Parallel, set the limit to 2, or add max: 2 on a new line at the same indentation as mode. Remove that extra line when returning to Single or Restart. The editor documentation describes the controls; blueprint-based automations do not offer this mode menu.

Here is the calculated timeline if the presses happen at exactly 0 and 5 seconds. It ignores processing overhead; use it to compare behavior, not to measure system performance.

Swipe sideways to read all columns.

Press the helper instead of selecting Run actions. This exercise needs real button-trigger data. A manual action run does not supply it and can make the message template fail. The testing documentation explains that distinction. When finished, disable the practice automation; you can then remove the practice helper and its notices.

4. Check the real routine before changing its mode

Restart stops steps; it does not undo them

Suppose a routine sets a lamp to bright, waits, then restores dim lighting. Restart can interrupt the wait before restoration. The lamp has already changed. Do not rely on the last step always running: a server restart or an error can also interrupt the sequence. The building-block documentation explains sequential execution and error stops.

For temporary lighting, use the separate scene snapshot and restore guide. Start with a nonessential lamp and keep its ordinary control available. Do not experiment with access controls, alarms, heating protection or shutoff routines.

A queue is not a physical-job scheduler

Consider a hypothetical routine with just “start cleaning this room.” If that action returns after sending the request, the automation has finished even though the vacuum is still cleaning. Queued mode can then send the next request too soon. A real room queue needs verified device status, a definition of completion, a timeout and a decision about failures. Those details depend on the exact integration; a twenty-second delay is not a substitute. If you add a wait for a reported state, check that it cannot pass immediately because the device still shows idle before the new job starts; its timeout also continues by default unless you choose otherwise.

The same distinction matters when calling another script. A direct call such as action: script.my_routine waits for that script; script.turn_on starts it separately and lets the caller continue. Check both the caller and the script’s own mode. See the script calling documentation. For the broader choice of building block, read scenes vs scripts.

Check changing conditions when the action actually runs

Top-level automation conditions decide whether a new request may join a queue. They are not a continuing permission check. For example, a noncritical announcement request may enter at 9:59 p.m. but wait until after quiet hours begin. Add another time condition in the action sequence immediately before speaking, if late announcements should be skipped. A condition in the sequence is checked when execution reaches it; see the Condition building block.

Likewise, Restart replaces a running automation only when the new request passes its top-level conditions. A failed condition is not a command to cancel the current run.

Keep the queue bounded and plan for interruptions

Queued and Parallel default to a limit of ten runs. For a queue, the active run counts toward that limit: max: 2 allows one active run plus one waiting. When the limit is reached, another request is refused. Silencing its log warning with max_exceeded changes logging, not that behavior.

A mode is not persistent storage. Home Assistant restarting stops active runs and loses pending waits and queued work. If a deadline must survive that, use the timer and restart-recovery guide, including its explanation of deadlines that pass while the server is off.

If the exercise does something else

Swipe sideways to read all columns.

The official troubleshooting guide helps interpret those traces. For a routine that never starts from its real event, use Tara’s automation-not-firing checks before changing its mode.

Common questions

Does Single mean once per day?

No. It stops overlapping runs of this automation. Once a run ends, another request can start it again. A once-per-day rule needs its own record or scheduling logic.

Can Queued stop two different automations fighting over a lamp?

No. Each automation manages its own runs. Two separate automations can still send conflicting commands. Give the shared behavior one owner, such as a deliberately designed shared script, and check that every caller uses it.

Does Parallel make one long sequence faster?

It allows multiple runs of the automation to overlap. It does not automatically turn the steps inside each run into parallel actions. Only use overlap when the copies can coexist safely.

For a household routine, the useful test is whether another person can predict what a second press will do. Tara’s local routines and coordinated controls page explains the planning approach. Keep that behavior clear before adding more triggers.