Home Assistant Single Execution Error: Safe Fix

Direct answer: “Stopped because only a single execution is allowed” means the automation was triggered again while an earlier run was still active and its mode was single. The second run was rejected. Do not switch blindly to parallel: first find what kept the original run open, then choose the mode that matches the job.

Quick diagnostic

Open the failed run in Settings → Automations & scenes → Traces.
Confirm the rejected run says runtime: 0.00 seconds.
Open the previous trace and find the active delay, wait, slow action, or loop.
Decide whether a new trigger should be ignored, replace the old run, wait its turn, or run independently.
Change the mode only after that decision, then reproduce the overlap safely.

What the message proves—and what it does not

The message proves that a second trigger arrived before the first run finished. It does not prove that Home Assistant is broken, that the trigger is duplicated, or that single is the wrong mode. Single mode is often the safest choice when overlapping commands could fight each other.

Home Assistant provides four modes: single refuses a new run; restart stops the active run and starts over; queued runs triggers in order; and parallel allows simultaneous runs. The correct choice depends on what the automation controls.

Ranked causes

1. A delay or wait keeps the first run active

This is the most common cause. A ten-minute delay, wait_for_trigger, or template wait means the automation remains active during that time. Another trigger is rejected in single mode even if no visible action is happening.

2. The automation triggers itself

An action may change the same entity used by its trigger. The new state change starts another run immediately, but single mode blocks it. Check the trace timeline and compare the trigger entity with every action target.

3. Multiple triggers occur close together

Two motion events, several device events, or two trigger definitions can arrive within seconds. This may be expected sensor behavior rather than a duplicate configuration. Use trace timestamps instead of guessing.

4. An action is slow or never completes

A service call, script, notification, or integration can take longer than expected. Inspect where the earlier trace is paused. Check the related integration before changing concurrency.

5. The first run is looping

A repeat block can keep running because its exit condition never becomes true. Inspect the live variables and set a bounded, safe stopping rule where appropriate.

Choose the mode by intended behavior

Desired behavior	Mode	Main risk
Ignore new triggers until the job finishes	`single`	A meaningful trigger may be skipped
Newest trigger should replace the old run	`restart`	Cleanup steps in the old run may not execute
Every trigger should run in order	`queued`	A backlog may build
Runs are independent and may overlap	`parallel`	Conflicting device commands or duplicate messages

For a light that should remain on for ten minutes after the latest motion, restart may fit because each new event resets the timer. For sequential announcements or jobs that must preserve order, queued may fit. For unrelated per-device notifications, parallel can be appropriate. Locks, doors, alarms, valves, heaters, and other consequential equipment deserve extra caution.

Safest fix sequence

Preserve evidence. Screenshot or export the two relevant traces and record their timestamps.
Find the open step. In the earlier trace, identify the exact delay, wait, loop, or service call still active.
Check for self-triggering. Compare trigger entities and events with action targets.
Define the intended overlap rule. Write one sentence: ignore, replace, queue, or overlap.
Change one setting. In the automation editor, open the menu and choose Change mode. Do not combine this with unrelated edits.
Test harmlessly. Trigger twice under controlled conditions and inspect both traces.

Example: a long delay in single mode

alias: Hall light timer
triggers:
  - trigger: state
    entity_id: binary_sensor.hall_motion
    to: "on"
actions:
  - action: light.turn_on
    target:
      entity_id: light.hall
  - delay: "00:10:00"
  - action: light.turn_off
    target:
      entity_id: light.hall
mode: single

Motion during the ten-minute delay is rejected. If the requirement is “turn off ten minutes after the latest motion,” restart may express that intent better. Confirm that stopping the earlier run cannot leave unsafe or incomplete work before changing it.

How to verify the repair

Reproduce the original timing. Confirm a new trace appears, the selected mode behaves as intended, and the controlled device reaches the correct final state. Test once after a Home Assistant restart during a safe maintenance window. Review the log for new maximum-run warnings or a queue that grows unexpectedly.

Prevention

Keep delays and waits visible and documented.
Use trigger IDs when several triggers have different meanings.
Avoid actions that change their own trigger unless the feedback is intentional.
Set reasonable limits for queued or parallel runs.
Review traces after replacing devices or changing entity IDs.

Frequently asked questions

Can I hide the warning?

Home Assistant can change the log level with max_exceeded, but silencing a warning does not restore a skipped run. Diagnose the overlap first.

Does “single execution” mean only one trigger is allowed?

No. An automation can have multiple triggers. The rule applies to simultaneous runs, not the number of trigger definitions.

Should I always use queued mode?

No. Queued mode preserves every run, which may be wrong for a timer or rapid sensor events. Match the mode to the required outcome.

Related Troubliq diagnostics

Sources and review record

Last reviewed: October 1, 2026. Examples are illustrative and should be adapted to the devices and safety consequences in your own installation.

Home Assistant “Stopped Because Only a Single Execution Is Allowed”: Choose the Right Automation Mode