An automation that worked for months quietly stops. The hallway light no longer comes on at dusk, the "leaving home" routine fires an hour after you leave, and nothing in the app looks wrong. The frustrating part is that everything still works when you tap the button manually.
Here is the short version: an automation is a chain — trigger, condition, hub, device, and sometimes a cloud service in the middle — and it fails at exactly one link. Almost nobody finds the fault quickly because they start changing settings before working out which link broke. Check the automation's own history first. Whether the trigger fired at all eliminates half the possibilities in seconds.
First, rule out the two impostors
Two problems look like automation failures and are not. Clear them before anything else, or you will spend an evening rewriting perfectly good logic.
The device is offline. If the target device is unreachable, the automation may be firing flawlessly into the void. Open the device in your app and toggle it by hand. If manual control fails too, this is a connectivity problem, not an automation problem — and for Wi-Fi gear the usual culprit is the 2.4GHz band trap that makes smart devices drop off the network, not the automation engine.
You are looking at the wrong automation. Duplicate or near-duplicate routines are extremely common, especially when a device's own app, a voice assistant, and a hub can each hold their own schedule. Search every app that touches the device for other rules pointing at it. A "broken" automation is often a working one being undone half a second later by a second rule you forgot you made.
The five links in the chain
Once the device responds manually and you know which rule you are debugging, the failure is at one of these points.
| Link | What it does | How it fails |
|---|---|---|
| Trigger | Detects the event that starts the rule | Sensor never reports, geofence never crosses, schedule offset misread |
| Condition | Decides whether to continue | A time window, mode, or presence check silently blocks it |
| Hub / engine | Evaluates the rule and issues commands | Hub offline, rule disabled, account or permission expired |
| Delivery | Gets the command to the device | Mesh routing, range, or radio congestion drops it |
| Device | Carries out the command | Local override, physical switch off, state not reported back |
Narrow it down with three checks
1. Read the history. Nearly every hub, assistant, and device app keeps a log of automation runs. If the log shows the automation ran, the fault is downstream — delivery or device. If it shows nothing, the fault is upstream — trigger or condition. This one check splits the problem in half and costs ten seconds.
2. Trigger it by hand. Most platforms let you run an automation manually. If a manual run does everything correctly, the actions are fine and your problem is the trigger or a condition. If a manual run also fails, stop looking at triggers entirely.
3. Isolate one element. Temporarily strip the automation to a single trigger and a single action, with no conditions. If the stripped-down version works, add pieces back one at a time. The piece that breaks it is your answer — and it is very often a condition nobody suspected.
Fix in order of likelihood
Work down this list. It is roughly ordered by how often each cause turns out to be the real one.
1. The trigger never fired
This is the most common failure by a wide margin, and each trigger type has its own weak point.
- Motion and presence sensors have a cooldown period after each detection during which they will not report again. If your automation seems to ignore you when you walk back into a room, you are probably inside that blind window.
- Contact and occupancy sensors report state changes, not continuous state. If the sensor missed a change, the platform believes the door is still open and no new "opened" event ever arrives.
- Geofencing depends on your phone giving the app background location permission and enough battery freedom to check position. Battery savers, permission resets after an OS update, and "allow only while using the app" are the usual suspects. A geofence that used to work and now fires late almost always lost a permission.
- Sunrise and sunset triggers need a correct location and time zone on the hub, not on your phone.
- Schedules can be silently skipped if the hub's clock has drifted or the rule was set in a different time zone.
2. A condition is silently blocking it
Conditions do not report failure — they just stop. Look for anything that narrows when the rule may run: a time window that no longer matches the season, a "only if nobody is home" check that thinks someone is home, a house mode or guest mode left switched on, or a "only if the light is off" guard that is false because the light is already on for another reason. Presence-based conditions are the most fragile, because presence itself is inferred from phones that go to sleep.
3. Two automations are fighting
If a light turns on and immediately off, or a thermostat bounces, you have competing rules. Common pairings: a hub automation plus a schedule inside the device's own app; a voice-assistant routine plus a hub rule; or two rules with overlapping time windows. Pick one place to own each device and delete the rest. Mixing platforms is convenient right up to the point where they disagree.
4. The command was sent but never arrived
If the log shows the automation ran and the device did nothing, look at delivery. Wi-Fi devices may be technically online but responding slowly. Zigbee and Z-Wave devices route through a mesh, and that mesh is built from mains-powered devices — remove or unplug a smart plug that was acting as a repeater and every battery device behind it can lose its path. Adding a mains-powered device between the hub and a distant sensor is a more reliable fix than moving the hub.
5. It depends on a cloud service
Automations that live in a vendor's cloud stop when your internet drops or the vendor has an outage, even though every device in your house is powered on and the hub is fine. If your automations fail as a group, and especially if they fail at the same moment as something else on your network, suspect the cloud rather than the rules. Where a platform supports local execution, moving critical automations (lights, locks, alarms) to local rules removes the dependency — that is a design choice worth making early, as covered in our smart-home starter guide.
6. The device was overridden locally
Physical switches still win. A smart bulb behind a wall switch that someone flipped off is unreachable, and an automation cannot fix that. Some devices also have a local "manual mode" or child lock that ignores remote commands until cleared.
When it only fails sometimes
Intermittent failures follow patterns, and the pattern names the cause.
- Fails at the same time every day — a schedule conflict, a mode change, or interference from something on a timer.
- Fails only when you are away — presence or geofencing, almost always.
- Fails after you touch a device manually — a state-tracking problem; the platform's idea of the device state no longer matches reality.
- Fails for a group of devices at once — hub, network, or cloud, not individual rules.
- Started after an app or firmware update — check permissions and re-authorise linked accounts; updates commonly reset both.
Build automations that fail less
A few habits prevent most of the above. Keep each device owned by one platform. Prefer triggers based on state ("door is open") over triggers based on events where the platform supports it, because state recovers after a missed message and events do not. Avoid long chains of conditions when a second, simpler automation would do. Give automations names you will recognise in a log six months from now. And where it matters — lights on stairs, locks, anything safety-adjacent — make sure the automation still works with the internet unplugged.
FAQ
Why does my automation work manually but not automatically?
Because the actions are fine and the trigger or a condition is not. Run the automation manually to confirm the actions, then check the log to see whether the trigger fired at all. If the trigger fired and the run stopped, a condition blocked it.
Why do my geofence automations fire late or not at all?
Geofencing depends on your phone reporting location in the background. Battery optimisation, restricted location permission, or a permission reset after an operating-system update will delay or prevent the crossing event. Set location access to "always" for that app and exempt it from battery optimisation.
Why did my automations stop working after adding a new device?
Two likely reasons. The new device may have brought its own default schedule that now conflicts with your rule, or you moved or unplugged a mains-powered device during setup and broke the mesh route that battery-powered sensors were using.
Do smart-home automations work without internet?
It depends where the rule is evaluated. Automations that run locally on a hub generally continue; anything evaluated in a vendor's cloud, including most voice-assistant routines, stops. If a whole group of automations fails at once, the cloud is a likelier cause than the rules.
Why does a light turn on then immediately off?
That is the signature of two automations disagreeing — usually a hub rule and a schedule inside the device's own app. Search every app that can control that device and delete the duplicate.
Next step
Next time an automation misbehaves, resist the urge to rewrite it. Confirm the device responds manually, then open the automation's history and answer one question: did the trigger fire? Upstream or downstream — that single answer sends you to the right half of this list and usually to the fix within minutes. For more practical, vendor-neutral tech guides and gear comparisons, visit MicroAllTech at https://microalltech.com.
