I have a rule that makes a few Smartthings API requests to get various device status. Since June 13th, 2025, one of the requests occasionally is repeated many times in the log (> 10 times, each with status = 200) and then rule execution stalls for several minutes and the rule finally progresses to completion. Heres some snips from the log:
Here’s the full rule screenshot … I should note that when variable $NotifyText changes, it triggers another rule to send an notification via the ST API
Are you referring to the rule Check Lights and locks VIII?
I pulled system logs looking for similar outbound HTTP requests from your log screenshots and it matched the rule ID associated with that rule name… and that rule configuration looks like the rule screenshot you shared.
But when I check the logs for the past ~3 days I’m not seeing the behavior you mentioned.
The logs for those that outbound URL seem to be spread out without close repetition or overlapping timestamps (CDT).
You had mentioned that it was since June 13th so I interpreted that to mean that it has consistently been an issue since that date, but did you perhaps mean that there was a timeframe around June 13th when the issue occurred?
There was a massive widespread outage with Google, AWS, and Cloudflare that lasted a few hours, so if it was around the 12th-13th but isn’t occurring anymore, I suspect it could have been fallout related to that event.
Yes, that’s the rule…It had been working great until last Friday night. The log I shared in the initial post was from 1:03am EDT this morning (6/19).
As is evident by the name of the rule, I have rewritten it several times over the years … I have another Smartthings automation that catches if the virtual switch that triggers this rule remains on > 15 minutes, which would prompt me to check logs for bugs etc.
and most of the times when the rule runs, it runs normally and finishes quickly. But occasionally it’s been getting stuck with this repeated http request behavior since this past Friday.
It seems to be something with the step that sets the $IG based on the Iron Gate - contact attribute that’s failing.
It almost seems like it’s failing to retrieve the contact attribute state, so the actions after the preceding ‘pause’ are retried (which makes sense since they are enqueued as retryable tasks), but it looks like we’re missing the relevant error catching / logging that would give us the insights we need.
I’ve made note of the issue so I can take a closer look when I’m back in the office next week.