Category: Home Assistant Automations

A Home Assistant automation can look correct and still fail to run. The quickest way to find the cause is to test the three separate stages: trigger, conditions, and actions. Avoid deleting and recreating the automation until you know which stage is failing.

1. Confirm the automation is enabled

Open Settings → Automations & scenes and select the automation. Check that its enable switch is on. If it was recently edited, save it and confirm the displayed configuration reflects the latest changes. Also check whether Home Assistant was restarted or restored from a backup around the time the problem began.

2. Open Traces before changing anything

Open the automation and choose Traces. Select the latest run, if one exists. A trace shows which steps executed and where processing stopped. If there is no new trace when you expect the automation to fire, investigate the trigger first. If a trace exists but the sequence stops, inspect the conditions and action steps shown in that run.

3. Test the trigger independently

Check the exact entity ID and the event that should start the automation. A state trigger for a light turning on is not the same as a trigger for its brightness changing. Likewise, a numeric-state trigger fires when a value crosses the configured threshold; it does not necessarily fire simply because the entity is already above that value when the automation is loaded.

• Open the triggering entity and confirm its current state and recent history.
• Check that the entity ID has not changed after renaming or replacing a device.
• For event, webhook, or device triggers, confirm the relevant event or device action is actually being received.
• For time triggers, verify the configured time and Home Assistant’s time zone.

4. Check every condition

One false condition can prevent all actions from running even when the trigger worked. Look for conditions involving time windows, presence, numeric thresholds, device states, or templates. Compare the values in the trace with the values you expected at that moment. Pay particular attention to exact entity IDs and capitalization in templates.

If several conditions are grouped together, remember that an ordinary condition sequence generally requires every condition in that sequence to pass. Test a suspected condition separately rather than removing all safeguards at once.

5. Run the actions manually—carefully

Use the automation’s action-run control only when it is safe to execute those actions immediately. Manual execution helps distinguish an action problem from a trigger problem, but it may not reproduce the original trigger variables or event data. A notification action might work manually while a template that depends on trigger data still fails during a real run.

Check the target entity, service/action name, required fields, and any template output. For physical devices, avoid manually testing actions that could unlock doors, open gates, disable alarms, or operate appliances unsafely.

6. Check logs and integrations

If the trace points to an action failure, open Settings → System → Logs and look for errors at the same time. A temporarily unavailable integration, authentication problem, or device that no longer responds can make an action fail even when the automation logic is valid.

7. Make one change, then retest

Change only the setting identified by the evidence. Save the automation, reproduce the original trigger, and check the next trace. Changing several triggers and conditions together makes it harder to identify the real cause.

Quick diagnosis

• No trace: check enable state, trigger configuration, entity ID, and whether the event occurred.
• Trace stops at a condition: inspect the condition’s actual inputs and expected values.
• Action reports an error: inspect logs, target entity availability, and action data.
• Manual run works but real trigger fails: compare trigger type, trigger variables, and conditions at the real event time.

The key is to use the trace as evidence. In most cases, identifying the first stage that fails is faster and safer than rebuilding the entire automation.

Official source: Home Assistant: Troubleshooting automations explains how traces help identify trigger, condition, and action failures.

\n

Review note: Checked against official documentation on October 19, 2026. This is a documentation-based guide, not a report of hands-on testing on a specific Home Assistant installation.

\n

Image credit: Unsplash, dada design.

Direct answer: If a Home Assistant Time Pattern automation runs once an hour when you expected it to run every few minutes, the most common mistake is entering a number such as 5 instead of an interval such as /5. In a Time Pattern trigger, 5 means the fifth minute of every hour; /5 means every five minutes.

The key difference: 5 versus /5

Home Assistant’s Time Pattern trigger uses a slash to express an interval. That distinction is easy to miss in the visual editor and can produce an automation that appears broken even though the YAML is valid.

The same idea applies to seconds, hours, and days where those Time Pattern fields support a pattern value.

Why the automation looks like it is “only running once an hour”

Suppose you want to check a sensor every five minutes. You open the automation editor and set Minutes to 5. Home Assistant accepts the configuration because it is a valid time pattern, but you have told it to react when the clock reaches five minutes past the hour.

The result is perfectly consistent:

• 10:05 — runs
• 11:05 — runs
• 12:05 — runs
• 12:10 — does not run
• 12:15 — does not run

That can look like a failed automation when the real problem is simply the meaning of the value.

How to set “every 5 minutes” correctly

1. Open Settings → Automations & scenes.
2. Open the automation that is running at the wrong frequency.
3. Find its Time pattern trigger.
4. In the Minutes field, use /5, not 5.
5. Save the automation.
6. Watch the trigger activity to confirm that it reacts at the expected times.

Home Assistant’s documentation specifically gives /5 as the pattern for running every five minutes and explains that a value without the slash represents an exact value.

What if you want every 10 or 15 minutes?

Use the same pattern:

• /10 = every 10 minutes
• /15 = every 15 minutes
• /30 = every 30 minutes

For evenly spaced intervals, choose a value that divides the hour cleanly. That makes the schedule predictable and easier to diagnose.

Don’t confuse “every five minutes” with “at minute five”

This is the most important distinction in this troubleshooting problem. A Time Pattern trigger is not asking, “How often should I run?” when you enter a plain number. It is matching a clock value.

Think of it this way:

5 asks: “Is the minute currently 5?”

/5 asks: “Is this one of the five-minute intervals?”

Check the other Time Pattern fields too

If the automation still behaves incorrectly, inspect Hours, Days, and Seconds as well. A correct /5 minute pattern can still be restricted by another field.

For example, if you specify an hour value as well as a minute pattern, the automation is no longer simply “every five minutes all day.” The additional time restriction becomes part of the trigger.

Use traces to prove what happened

Don’t rely only on whether a light or notification changed. Open the automation’s traces or trigger information and confirm when Home Assistant actually reacted.

A trace is especially useful when the automation has several triggers or when the action itself has additional conditions. If the time trigger fires but the action does not happen, you may have moved beyond a trigger-frequency problem and into a condition or action problem.

What if it runs at the right interval but the action still doesn’t happen?

Then the Time Pattern may already be working correctly. Home Assistant evaluates conditions after a trigger fires. If a condition is false at that moment, the automation can stop before its actions execute.

For example, an automation could check a temperature every five minutes but only turn on a fan when the temperature is above a threshold. The trigger can fire correctly at 12:00, 12:05, 12:10 and so on while the fan remains off because the condition is not met.

What if you need to check something continuously?

A Time Pattern trigger is useful when the requirement is genuinely periodic: check every five minutes, every ten minutes, and so forth.

But if what you really want is “do something immediately when the value crosses a threshold,” a state or numeric-state trigger may be a better design. Polling every five minutes can introduce a delay and may miss the exact transition you care about.

Quick diagnostic checklist

1. Runs once per hour: check for a plain minute value such as 5.
2. Should run every five minutes: change it to /5.
3. Still doesn’t perform the action: inspect the trace for conditions that failed.
4. Trigger never appears: check that the automation is enabled.
5. Wrong clock time: check Home Assistant’s configured time zone.
6. Multiple triggers: confirm another trigger is not changing the expected behavior.

Example: a simple five-minute check

If your goal is to periodically evaluate a condition, the important part of the automation is the time-pattern trigger. Conceptually, the schedule is:

minutes: "/5"

The trigger starts the automation at five-minute intervals. The conditions then decide whether the actions should actually run.

When you should use a different trigger

Use a Time Pattern trigger when you intentionally want periodic checks. Use an event, state, numeric-state, device, or other appropriate trigger when the automation should respond to a specific event as it happens.

For example, “turn the light on when motion is detected” normally does not need a five-minute timer. “Check every five minutes whether the humidity is still above my threshold” is a much better fit for a periodic trigger plus a condition.

Frequently asked questions

Why does Home Assistant run my automation at 5 minutes past every hour?

Check the Time Pattern trigger. A minute value of 5 means the fifth minute of each hour. It is different from /5, which means every five minutes.

Does /5 mean exactly five minutes after the automation starts?

No. It follows the clock pattern. It is an interval pattern based on the clock rather than a five-minute countdown that begins when the automation is enabled.

Can I use /10 or /15?

Yes. Those patterns represent ten-minute and fifteen-minute intervals respectively.

Why does the trigger run but my device doesn’t change?

Check the trace for conditions and actions. A trigger can fire correctly while a condition prevents the action or an action fails.

Sources and testing note

This guide was checked against Home Assistant’s current automation documentation on October 8, 2026. It is a documentation-based troubleshooting guide, not a claim of testing on a particular Home Assistant installation.

• Home Assistant: Troubleshooting automations
• Home Assistant: Automation triggers
• Home Assistant: Testing automations

Related Troubliq guides

• Home Assistant automation stopped triggering
• Home Assistant automation runs twice
• Home Assistant stopped because only a single execution is allowed

Direct answer: If a Home Assistant automation runs twice, do not assume Home Assistant is randomly duplicating it. The usual causes are two triggers responding to the same event, a state trigger reacting to attribute changes, or a time trigger landing in a repeated clock hour. Start with the automation trace and identify the trigger that created each run before changing the automation. For the full step-by-step diagnosis, see the complete trace-based guide.

What “runs twice” actually means

First separate two different symptoms. If you see two traces starting almost together, the automation may have been triggered twice. If you see one run but an action happens twice, inspect the action itself, scripts it calls, or another automation that controls the same device. Those are different problems and need different fixes.

1. Check the traces before editing anything

1. Open Settings → Automations & scenes and select the automation.
2. Open Traces and compare the two runs.
3. Look at the trigger information and timestamps.
4. Write down the entity, event, time trigger, or other trigger that started each run.

Home Assistant’s current troubleshooting documentation recommends using traces to determine why an automation ran. Preserve that evidence before changing the trigger configuration.

2. Look for two triggers responding to one change

An automation can contain multiple triggers. Two of them may legitimately react to the same real-world change. For example, a device event can be accompanied by a state change, or two closely related event sources can both call the same automation.

Compare the trigger that fired in each trace. If both traces point to different triggers, decide whether both are actually required. If only one trigger should start the workflow, remove the redundant trigger rather than adding delays or helpers to hide the duplicate.

3. Check whether a state trigger is also reacting to attributes

A state trigger can react when an entity’s attributes change, not only when its main state changes. A light may keep the same on state while brightness changes; a sensor can keep the same state while an attribute updates.

If the automation should respond only to a particular state transition, make the trigger explicit with the appropriate From and/or To state. Home Assistant documents this as a common reason an automation appears to run more often than the visible state changes.

4. Check time triggers and daylight-saving transitions

If the duplicate happens at a clock time rather than immediately after a device change, check the time trigger. Home Assistant documents a special case when clocks move backward: a time that occurs during the repeated hour can occur twice that day.

That is different from a permanently duplicated automation. If the behavior happens only on the daylight-saving transition, do not rewrite the automation simply to compensate for one repeated clock hour. Choose a time outside the affected hour when the job must occur exactly once.

5. Check whether another automation or script is doing the same job

Sometimes the automation is not actually running twice. A second automation, script, blueprint, device routine, or manufacturer cloud rule may control the same light, switch, scene, or notification.

Search for other automations and scripts that reference the affected entity. Then test the target action with the smallest safe change. A duplicated notification is especially useful evidence: if the automation has one trace but the notification appears twice, the duplication may be downstream.

6. Do not use the automation mode as the first “fix”

Automation mode controls what happens when a new run starts while an existing run is still active. It does not, by itself, identify why two triggers occurred.

• Single: a new run is not started while one is already running.
• Restart: a new run stops the previous run and starts again.
• Queued: new runs wait for earlier runs, subject to the configured limit.
• Parallel: multiple runs can execute at the same time, subject to the configured limit.

If your traces show two genuine triggers, changing the mode can change the symptom without removing the cause. Diagnose the trigger first.

A safe diagnostic sequence

1. Reproduce the duplicate once.
2. Compare the two traces and record their trigger IDs or trigger descriptions.
3. Identify whether the triggers are different or the same.
4. If they are different, inspect whether both are necessary.
5. If the trigger is a state trigger, check whether attribute changes are involved.
6. If it is time-based, check the time zone and whether the duplicate matches a daylight-saving transition.
7. Search for another automation, script, blueprint or device routine acting on the same target.
8. Make one small change only.
9. Reproduce the original condition and confirm the trace count and final device behavior.

How to verify the fix

Do not stop after seeing one successful run. Recreate the original trigger at least twice under normal conditions. Confirm that the expected automation trace appears once, the intended action happens once, and the target entity reaches the expected state.

If the original problem was intermittent, leave the configuration unchanged long enough to cover the interval in which the duplicate normally appeared. Remove temporary test helpers or extra logging after the diagnosis.

When the problem is not an automation duplicate

If Home Assistant shows one trace but a device changes twice, look downstream. Check scripts called by the automation, scenes, other automations, device-side routines, and integrations that can independently issue commands. If the trace itself shows two starts, stay focused on triggers and timing first.

Frequently asked questions

Can a state trigger run twice without the device visibly turning on and off?

Yes. Attribute changes can cause a state trigger to fire even when the displayed state remains the same, depending on how the trigger is configured.

Should I change Single to Parallel?

Not just because an automation appears to run twice. Mode changes affect concurrency; they do not explain the original trigger. Identify the duplicate trigger first.

Why would a time automation run twice only once a year?

A daylight-saving clock change can repeat an hour. Home Assistant documents that a time trigger scheduled during the repeated hour can therefore occur twice on that day.

What is the fastest evidence to collect?

Capture the two trace timestamps, the trigger that started each run, and the target entity or action that duplicated. That usually separates trigger duplication from downstream duplication quickly.

Sources and testing note

This guide was checked against Home Assistant’s current automation troubleshooting documentation on October 3, 2026. It is a documentation-based troubleshooting guide, not a report of hands-on testing on a particular Home Assistant installation.

• Home Assistant: Troubleshooting automations
• Home Assistant: Automation triggers
• Home Assistant: Automation modes

Related Troubliq guides

• Home Assistant automation stopped triggering
• Home Assistant stopped because only a single execution is allowed
• Smart-home diagnostic decision tree

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.

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

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

1. Preserve evidence. Screenshot or export the two relevant traces and record their timestamps.
2. Find the open step. In the earlier trace, identify the exact delay, wait, loop, or service call still active.
3. Check for self-triggering. Compare trigger entities and events with action targets.
4. Define the intended overlap rule. Write one sentence: ignore, replace, queue, or overlap.
5. Change one setting. In the automation editor, open the menu and choose Change mode. Do not combine this with unrelated edits.
6. 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

• Automation stopped triggering
• Automation runs twice
• Smart-home diagnostic decision tree

Sources and review record

• Home Assistant: Automation modes
• Home Assistant: Automation editor
• Home Assistant: Troubleshooting automations
• Home Assistant: Automation YAML

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