Blog

Short answer: Open the automation trace and confirm whether the trigger fired. If no trace exists, inspect the trigger and source entity. If a trace exists, follow it through conditions and actions instead of editing several steps at once.

Preserve the failure

Record when the automation last worked, the expected trigger time, the relevant entity states, and recent changes to Home Assistant, integrations, devices, helpers, or YAML. Do not delete and recreate the automation yet.

1. Confirm it is enabled

Check that the automation is enabled and that its mode is appropriate. Review the logbook for an unexpected disable event, reload, restart, or conflicting automation.

2. Look for a trace

A trace shows whether the trigger fired and where execution stopped. No trace usually points toward the trigger, source entity, or scheduling context. A trace ending at a condition means the automation worked as written but the condition evaluated false.

3. Inspect the trigger

Check entity IDs after device replacement or integration migration. For state triggers, distinguish a true state change from an attribute update. For numeric triggers, remember that crossing a threshold is different from already being beyond it. For time triggers, check the system timezone and helper value.

4. Test conditions with real states

Use the trace values from the failed run. Templates may receive unavailable, unknown, text, or null values. Confirm units and data types rather than assuming the displayed dashboard value is the raw state.

5. Test actions safely

Run only actions that are safe to test. Avoid unlocking doors, disabling alarms, opening valves, changing HVAC safety settings, or operating equipment without supervision. Verify target entities, service names, permissions, and integration availability.

6. Check concurrency

Single, restart, queued, and parallel modes behave differently when triggers overlap. A long delay or wait can make a single-mode automation appear unresponsive. The trace and system log should show dropped or cancelled runs.

Make one change

Duplicate or export the automation before a structural edit. Change one confirmed cause, reload if required, reproduce the trigger, and compare the new trace. If the failure began after an update, consult current release notes and official documentation before applying a workaround.

Video walkthrough: trace an automation failure

Michael Leen demonstrates how to follow Home Assistant automation traces and isolate the exact trigger, condition, or action that stopped a run. Use the video as a visual companion to the checks above; keep the written steps open so you can record each result and change only one variable at a time.

Video: “Home Assistant Automation Not Working? Do THIS First!” by Michael Leen. Embedded from the creator’s original YouTube upload.

Official sources

• Home Assistant automation testing and troubleshooting
• Home Assistant automation modes

Last reviewed: September 4, 2026.

Find your next troubleshooting path

• Home Assistant automations hub
• Smart-home diagnostic decision tree
• MQTT entities unavailable after restart

Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.

Detailed evidence checklist for Home Assistant automation stopped triggering

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.

Verification checkpoint 1 focuses on trigger observation. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 1: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

For checkpoint 2, inspect trace creation rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 2: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Checkpoint 3 — condition result: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 3: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Verification checkpoint 4 focuses on choose branch. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 4: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

For checkpoint 5, inspect target entity rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 5: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Checkpoint 6 — automation mode: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 6: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Verification checkpoint 7 focuses on delay or wait. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 7: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

For checkpoint 8, inspect template variables rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 8: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Checkpoint 9 — YAML reload: reproduce the original symptom once and record the result at the expected update interval. Compare it with the last known-good behavior. Keep the change only when this specific checkpoint improves the failure without creating a new warning; otherwise restore the previous value.Validation note 9: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Verification checkpoint 10 focuses on service response. Observe the relevant state, event or log through two normal cycles and write down the timestamp. If the result is unchanged, undo the experimental change before testing another layer so the diagnosis remains controlled and reversible.Validation note 10: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

For checkpoint 11, inspect restart behavior rather than relying on the dashboard icon alone. Confirm the expected input, the system response and the returned state. Preserve the evidence, reverse any ineffective adjustment and move to the next checkpoint only after the current result is clear.Validation note 11: Recheck the symptom after a normal interval, compare it with the incident record, and document whether the latest change improved, worsened, or did not affect the failure. Restore the previous value when a test provides no benefit so unrelated changes do not accumulate.

Separate trigger failure from condition or action failure

Open the automation trace before editing YAML. If no trace exists for the expected event, the trigger did not fire. If a trace exists and stops at a condition, the trigger worked and the condition evaluated false. If the trace reaches the action sequence, inspect the exact action result, target and service response. This distinction prevents rewriting a correct trigger when the real problem is downstream.

In Developer Tools, observe the entity state or event that should start the automation. State triggers compare exact state strings and do not behave like numeric comparisons. Numeric-state triggers fire when a value crosses a threshold, not continuously while it remains beyond that threshold. Time, sun, template and event triggers each have their own restart and availability behavior.

Check modes, waits and overlapping runs

Review the automation mode. In single mode, a long delay or wait can block a new run. Restart mode cancels the previous run, queued mode preserves order, and parallel mode permits overlap. Choose the mode based on the device and intended behavior; changing it without understanding concurrency can create duplicate commands.

Inspect wait templates, choose branches and templated targets using real trace variables. Confirm entity IDs still exist after device replacement or integration reload. A dashboard label may look unchanged while the underlying entity ID has changed. Reload automations after YAML edits and check the configuration before restarting Home Assistant.

Verify the automation deterministically

• Reproduce the actual trigger instead of pressing “Run actions” only.
• Confirm the trace shows the expected trigger data.
• Check every condition result and selected choose branch.
• Verify the target entity receives the service call.
• Repeat after a normal reload or restart.

Running actions manually bypasses triggers and may bypass trigger-dependent variables, so it cannot prove the complete automation works. Use a safe test value or event, capture one trace and restore the original state afterward. If the automation fails only after restart, examine unavailable startup entities, template initialization and required delays rather than adding arbitrary repeated actions.