Automation modes in Home Assistant: single, restart, queued, parallel

🏠 Home Assistant

Automation modes in Home Assistant: Why the default isn't your friend

Home Assistant automation modes decide what happens when an automation is triggered again while it is still running. Here is when to use single, restart, queued, or parallel.

Franck Nijhof

Jun 14, 2026

7 min read

Photo by Emilipothèse / Unsplash

Today I want to talk about something tiny in Home Assistant that explains a lot of “why did nothing happen?” moments: automation modes.<br>You know that moment when you press a button twice and the second press appears to do absolutely nothing? Or when a motion light turns off even though someone is still in the room? Often, the automation did exactly what you told it to do. The problem is that the default behavior was not what you expected.<br>Automation modes decide what happens when the same automation is triggered again while it is still running. That sounds like a small detail. It is not. It changes whether Home Assistant ignores the new trigger, restarts the automation, queues it, or runs another copy next to the first one.<br>The short version<br>Home Assistant has four automation modes:

ModeWhat happens when it is triggered again while running?Use it when...

singleThe new trigger is ignored.You intentionally want a cooldown or throttle.<br>restartThe current run stops and a new run starts.The latest trigger should win.<br>queuedThe new run waits until earlier runs finish.Every trigger matters, but overlap is not safe.<br>parallelA new independent run starts immediately.Runs are independent and safe to overlap.

The default for automations is single. That is conservative, safe, and historically sensible. It is also the reason a lot of automations quietly drop triggers.<br>So my practical advice is simple: do not leave the mode implicit once an automation gets even slightly interesting. Pick the behavior you actually want.<br>Automation modes decide what happens when the same automation is triggered again while it is still running.Let me break down each one:<br>Single<br>This is the default mode. When a new trigger comes in while the automation is still running, it just gets ignored. Home Assistant will log a warning, but that's it. The trigger is dropped.<br>This can be useful for simple throttling when you pair it with a delay at the end, but honestly? It drops legitimate work, and that's usually not what you want. For scripts especially, this default causes silent failures that you might not notice for weeks.<br>Restart<br>This mode says “latest intent wins”. When a new trigger arrives, it aborts the current run and immediately starts fresh. This is perfect for things like motion sensors keeping lights alive, or when you're adjusting a dimmer and want it to follow your most recent command.<br>Here's something important that catches people off guard: restart mode checks conditions before it actually restarts. If motion triggers again while your lights are on, but someone manually turned off the light in the meantime, the automation won't restart because the conditions aren't met anymore. This is actually a good thing because it prevents unwanted behavior, but it surprises people who expect unconditional restarts.<br>Queued<br>This one lines up triggers and executes them one after another. No triggers get dropped while there is room in the queue, and nothing overlaps. You can set a max to control how many triggers can wait in line (the default is 10).<br>This is ideal when actions absolutely cannot overlap, but you still want every trigger to be honored. Think doorbell chimes or commands to a device that can't handle multiple requests at once.<br>Here's the big gotcha with queued mode: conditions are evaluated when the trigger happens, not when the automation actually runs. If your automation triggers while busy and the conditions pass at that moment, it joins the queue. But if those conditions change while waiting in line, it doesn't matter. The automation will still run when it reaches the front of the queue. This is probably the most commonly misunderstood aspect of automation modes.<br>Parallel<br>This mode spins up multiple runs at the same time. It's only safe if your actions don't conflict with each other. You can also set a max here to control how many runs can happen simultaneously.<br>Great for things like sending notifications to multiple targets or kicking off independent tasks that don't step on each other's toes. This is often the best choice for reusable scripts that get called with different parameters.<br>Mode applies to the whole automation<br>This trips people up constantly: the mode is not per trigger. It applies to the entire automation or script.<br>If an automation has three triggers and it is already running because trigger A fired, then trigger B and trigger C are also subject to that same mode. With single, they are ignored. With restart, they restart the whole automation. With queued, they join the same queue. With parallel, they start...