Automations not running reliably

[Andybobandy]

I’ve been using Google home for at least 3 years now. Every once in a while in the past there has been an issue where an automation failed. Wasn’t a huge deal because it happened very rarely. Now, I have automations either fail to run in their entirety or fail to execute all actions on a near daily basis. I live alone and also work long hours. The automations I use to close my automatic blinds and turn on the lights help prevent my house from getting robbed while I’m away. I would not have invested in 7 different Google speakers/hubs if I knew that one day my routines would just randomly decide to stop working consistently. I’m also not the only person having these problems based on the forums. Can Google please look into this before I throw all of my Google devices in the trash and switch to Alexa? It’d be a gigantic pain to switch my entire ecosystem over to a competitor, but if Google isn’t going to be consistently reliable and no effort is going to be made to fix it that’s realistically what I’m going to have to do.

Please do not give me the troubleshooting steps. I am already aware of them. They did not fix my issue.

Multi step automations (or those that use device triggers) seem to be having issues most consistently. Google isn’t consistently recognizing when a device state is changed via another routine. The following device state change triggered automation isn’t showing in the activity tab maybe about 25% of the time despite the device itself changing state as it’s supposed to—when a routine that changes that device state even runs to completion that is.

Is this being looked into in any serious way? I see other similar forum posts going back to September of 2025–which is also right around when I started having issues. Thanks

[Andybobandy]

Also important note: it is not the Internet itself. I work for an ISP installing internet in other people's homes. I have all of the tools to verify the service is working the way it’s supposed to at my own home and can verify that it isn’t part of the problem.

[kcruzgonzalez]

Hi @Andybobandy,

Thank you for posting in the community. I can understand that your automations have become unreliable, failing to execute either partially or entirely on a near-daily basis. I'm sorry for the trouble this has caused, especially given that you rely on these routines for home security while you are away at work. Don't worry, I'm here to help, and I'm confident we can work together to get your ecosystem back to the consistent performance you've had over the last few years.

The technical insight here involves the "device trigger" logic you mentioned. When an automation is triggered by another device's state change, there is a specific handshake that must occur between the Google Home cloud and the manufacturer's server. If the activity tab isn't logging the trigger, it suggests a "silent failure" where the state change is recognized locally or at the manufacturer level but isn't being successfully broadcasted back to the Google Home execution engine. This often stems from a breakdown in the linked service token or a specific conflict in multi-step routine logic.

To help me narrow this down, could you please answer the following questions?

• Which specific brands of smart blinds and lights are you using in these automations?
• Are these routines "standard" routines created in the app, or are they "scripted automations" using the YAML editor?
• Have you noticed if the failures occur more frequently when the "Starter" device is triggered manually versus when it is triggered by another automation?
• Since the issues began around September 2025, have you tried unlinking and relinking the manufacturer's service (e.g., Phillips Hue, Lutron, etc.) in the "Works with Google" section?

Let me know that information so I can continue helping you.

Regards,

Kevin

[Andybobandy]

They are Yoolax blinds that use a Bluetooth gateway that is hardwired directly to the router. When the routine actually gets to the point where the blinds should close (there are other actions before and after), the command is shown in the Yoolax app, the Google home app under activity, and the blinds typically actually close. The lights are all Cync brand (“lights on” is a separate device triggered routine that is linked to a virtual button in Samsung SmartThings so that I can use it in multiple different routines by turning the one “switch” on) and it has the same issue as before. It appears as though my routines through Google home either fail to execute entirely or that they stop halfway through. When the routine actually gets to the step where the device trigger that changes light state turns on, the routine normally executes as intended. The main problem is that the routine isn’t making it to that point consistently. If it does make it that far though, the following routine may still stop midway through.

Occasionally, the device trigger may show it was turned on in my activity, followed by a notification saying “routine started because device changed state”, but that routine doesn’t actually execute at all. Sometimes the same thing will happen but the routine will not execute all actions. Other times, the device trigger may show under “my activity”, but there is no follow up notification saying “routine started because device changed state”. In that scenario, obviously, the following routine doesn’t start either.

They are standard routines scripted through the app—the ones created via “routines” in home settings>Google assistant>routines tend to work much more reliably than the new Gemini “automations” that are the default for new routines/automations now.

The routines/automations fail or stop midway through when triggering manually by pressing the “play” button in the Google Home app just as often as they do when running on their own/when triggered by another automation.

I have relinked everything in the “works with Google” section and it did not fix the issue.

I do not think it’s an issue with the smartthings virtual devices either. The lights are the only part that uses that. This issue also started before I began incorporating virtual devices into my routines.