Why Do My Home Assistant Automations Stop Running After a Restart?
- State trigger requires a from state that was not restored after restart
- Automation initial_state not set causing automation to default to off after restart
- Integration providing the trigger entity not fully loaded when automation evaluates
Problem Description
Your Home Assistant automations work correctly until Home Assistant is restarted, after which some or all automations stop triggering even though they show as enabled in the automation list. State-based triggers that require knowing a previous state do not fire after a restart because Home Assistant has no history of the previous state from before the restart. Time-based triggers may also miss their scheduled time if the restart takes longer than expected.
Why This Happens in Real Homes
The number one cause is state-change triggers with a from clause. After restart, HA does not know the previous state of most entities, so a trigger waiting for a specific state change never fires. Remove the from clause or add a homeassistant started trigger as a backup. The number two cause is cloud integrations being slow to load — add a 60-second delay to anything that depends on Tuya, Google, or Alexa entities.
Symptoms
- Automations that were running stop triggering after Home Assistant restart
- State change triggers do not fire in the first minutes after HA restarts
- Automations show as On in the list but do not execute on trigger events
- Time-based automations miss their scheduled time on the day of a restart
- Automation trace shows no records after a restart for triggers that should have fired
- Some automations resume after restart but others stay dormant indefinitely
Recognize these? Here's what usually causes it.
Common Causes
- State trigger requires a from state that was not restored after restart
- Automation initial_state not set causing automation to default to off after restart
- Integration providing the trigger entity not fully loaded when automation evaluates
- Template in trigger or condition using unavailable entities during startup
- Automation mode set to single with a queued run that blocks new triggers
- Home Assistant recorder not restoring entity states quickly enough on boot
Most fixes happen in the first 3 steps.
Do not create restart-triggered automations that unlock doors, disable alarms, or open garage doors without a confirmation condition. If HA restarts unexpectedly (power outage, crash, update), these automations would fire automatically — which is a security risk. Always add a condition that checks the time of day or requires manual confirmation for security-sensitive actions.
Step-by-Step Solution
Check if automations are disabled after restart
Go to Settings > Automations. If any automation shows a toggle in the Off position after restart, it was not set to auto-enable. In YAML automations, add initial_state: true to make sure they turn on after every restart. In the UI editor, check the automation settings — there is an option to control whether it starts enabled.
Fix state-change triggers that need a from value
The most common reason automations do not fire after restart: the trigger waits for a state change FROM a specific value, but after restart, the entity has no previous state. For example, a trigger that fires when a light goes from off to on will never fire if HA does not know the light was off before restart. Remove the from clause, or add a separate homeassistant started trigger.
Add a startup trigger for critical automations
For automations that must run after restart (security, climate, lighting schedules), add a second trigger: platform homeassistant, event start. This fires once HA is fully loaded. Combine it with a condition that checks current state so it only acts if needed. This guarantees the automation re-evaluates after every restart.
Add a startup delay for cloud-dependent automations
Integrations like Google Home, Alexa, Tuya, and cloud cameras take 30-120 seconds to fully load after HA starts. If your automation triggers before the integration is ready, it fails silently. Add a delay of 60-120 seconds after the homeassistant started trigger, or use a wait_template that checks if the entity is available.
Check automation traces for the failure point
Go to Settings > Automations, click the automation, then click Traces. Each trace shows exactly what happened: whether the trigger fired, whether conditions passed, and whether actions executed. After a restart, check traces for your problem automations. If there are no traces at all, the trigger never fired — which usually means a from-state issue or the entity was unavailable.
Check integration load order with slow integrations
Some integrations (Zigbee, Z-Wave, Bluetooth) take longer to initialize. If your automation depends on a Zigbee sensor, but Zigbee has not finished loading when the automation evaluates, the entity shows as unavailable and the automation skips. Check the HA log after restart for integration load times. If a specific integration is slow, increase the startup delay for automations that depend on it.
Avoid single mode for automations that queue during restart
If your automation mode is set to single (the default) and it gets triggered during startup while a previous instance is still queued, the new trigger is dropped. For critical automations, consider setting the mode to restart or queued. This prevents a startup race condition from silently blocking the automation.
Quick Solutions
Still having issues? This is usually the deeper cause below.
If this comes back after following these steps, check whether a recent app or firmware update reset a default setting — the fix works, but the setting gets reverted silently.
Create a simple test automation that sends a notification to your phone when Home Assistant finishes starting. Use trigger platform homeassistant event start with a 2-minute delay. When you get the notification, you know HA is fully loaded and all automations should be active. This also gives you a restart timestamp in your notification history.
Home Assistant issues that only appear after restart are a well-known quirk — triggers that require prior state history simply can't fire until that history rebuilds.
- State trigger requires a from state
- Automation initial_state not set
- Integration providing the trigger entity not fully loaded
- Template in trigger or condition using unavailable entities during
- Automation mode set to single with a queued run
Before you go — try one of these (they fix most cases).
Most popular upgrades chosen by Home Assistant owners.
Home Assistant Connect ZWA-2 | Connect Z-Wave devices to ...
Zooz 800 Series Z-Wave Long Range GPIO Module ZAC93 LR (U...
Home Assistant Connect ZBT-2 | Connect Zigbee, Thread, or...
As an Amazon Associate we earn from qualifying purchases.
Official Manufacturer Manual
Home Assistant provides official product documentation through their online manual rather than downloadable PDF. Access setup guides, troubleshooting steps, and product specifications for your Home Assistant.
Source: home-assistant.io
Need More Help? Home Assistant Support
Note: The contact information below connects you directly to Home Assistant's official customer support team, not Trunetto. They can help with warranty claims, device replacements, and advanced technical issues.
Guide Improvements
- Updated June 16, 2026
Added specific automation debugging steps including entity availability checks, startup trigger delays, and YAML validation.
What changed:- Added entity availability checks after restart
- Added startup trigger delay configuration
- Added automation trace debugging steps
- Added real-world context about common restart issues
Source: Trunetto editorial update
