The short answer
Read the activity log first, because it will show whether the automation ran at all. If it never triggered, the problem is the trigger or its conditions. If it triggered and nothing happened, the problem is the devices or the platform reaching them. Those are two entirely different investigations.
An automation has three parts: a trigger, optional conditions, and actions. Failures divide neatly between them, and every major platform keeps a history that tells you which part failed. Reading that log first saves a great deal of guessing.
Step 1: did it run?
- Google Home: the Activity or History view shows automation runs.
- Alexa: routines show recent activity, and the Alexa Privacy voice history shows triggered commands.
- Apple Home: accessory activity is limited, and the Home app shows automation status and whether it is enabled.
- SmartThings and Home Assistant: both keep detailed logs including the trigger and each action’s result.
If the log shows the automation ran and the light did not come on, the device or the connection is at fault. If there is no entry at all, the trigger never fired.
Step 2: triggers that quietly fail
- Sunset and sunrise triggers depend on the home location being set correctly. A home set to the wrong city runs automations at the wrong time all year.
- Geofence triggers need location permission set to always, and background location on the phone. Battery optimisation suppresses them, which is the most common cause of a location automation that works sometimes.
- Time triggers can be affected by time zone settings and by daylight saving transitions.
- Sensor triggers depend on the sensor reporting. A battery sensor that has gone flat stops triggering without an obvious error, and its last known state remains displayed.
- Device state triggers can miss changes that happen while the hub is offline, since the state change is never observed.
- Presence triggers based on Wi-Fi fail when the phone sleeps its connection overnight.
Test a trigger in isolation by creating a temporary automation with the same trigger and a single obvious action, such as a light flashing. That tells you whether the trigger works without the complications of conditions and multiple actions.
Step 3: conditions that block silently
Conditions are where automations most often fail invisibly, because a blocked automation looks identical to one that never triggered.
- Time windows that no longer match your routine, particularly ones set during a different season.
- Presence conditions requiring everyone to be home or away, where one person’s phone has stopped reporting.
- Device state conditions referring to a device that has been removed or renamed.
- Mode or house state conditions, such as home, away or night, which may not be changing as you expect.
- Another automation that has already set the state, so a condition checking for the opposite never matches.
Step 4: actions that fail
If the log shows the automation ran but the result did not happen:
- The device was offline, which the log will usually say. Check its connection and battery.
- The device was renamed, which breaks automations referring to the old name on some platforms.
- A cloud service was down, affecting only devices from that manufacturer.
- The action was too fast after the trigger, particularly with devices that take a moment to wake. Adding a small delay fixes surprisingly many of these.
- A subsequent automation reversed it within seconds. Two automations fighting is common and confusing, and the log shows both.
Automations that were built in a manufacturer’s app and then partly recreated in a platform app frequently conflict. Choose one place to keep automations and remove the duplicates, because debugging automations spread across three apps is far harder than it needs to be.
Step 5: the platform itself
- Check for an outage, which affects cloud-run automations entirely.
- Check the hub is online, since local automations run there.
- Check whether the automation is enabled, as some platforms disable automations that error repeatedly.
- Check account access, since a household member removed or a re-authentication prompt unanswered can stop automations involving their devices.
- Check after app updates, which occasionally reset or migrate automations imperfectly.
Building automations that do not break
Keep them simple
One trigger, few conditions. Complex automations fail in complex ways and are hard to debug months later.
Use local execution where possible
Matter, Thread, Zigbee or a local hub. Automations that do not depend on the internet fail far less often.
Name devices clearly and never rename them
Renaming breaks references on several platforms.
Add a small delay before actions
Especially for devices that sleep. Two seconds costs nothing and prevents commands arriving before the device is listening.
Keep all automations in one place
One app, not spread across the manufacturer’s app and the platform’s.
Document what you built
A note of what each automation does and why. In a year you will not remember, and neither will anyone else in the house.
Why does my sunset automation run at the wrong time?
The home location is set incorrectly, so the platform calculates sunset for the wrong place. Check the home address in the app’s settings.
Why do location-based automations work inconsistently?
Phone battery optimisation suppresses background location updates. Set the app to unrestricted battery use and location permission to always.
My automation ran but the light did not come on. Why?
The device was offline, renamed, or the command arrived before it was ready. Check the device’s connection and try adding a short delay before the action.
Can two automations conflict?
Frequently. Two routines controlling the same device, one reversing the other within seconds, is one of the most common causes of apparently random behaviour. The activity log shows both.
Do automations work without internet?
Local ones on a hub do. Cloud automations do not. That difference is the main practical argument for a local platform or Matter devices.
The order
Read the log to find out whether the automation ran. No entry means the trigger or a condition; an entry with no result means the device or the connection. Test triggers in isolation with a simple action. Check for conditions that no longer match, and for a second automation reversing the first. Then simplify what you have built, keep it in one app, and prefer local execution.
