Mitch

I've seen a couple articles discussing how automations are every hour, but not "on the hour" - I'm wondering about the finer points of timing an automation... i.e. if you have a multi-step process - like step 1, 2, 3, 4 and you want them separated by "an hour", how do you ensure that the steps are not separated by more than an hour?

In theory (and from what I think I've observed) a multi-step process can seem to SOMETIMES take 2 hours between steps.

Presumably this comes down to the logic where it's been "at least" an hour since the last run...

0 hours 59 minutes and 59 seconds is less than an hour - so that run is skipped...

The next run is around 1:59 from the initial event.

Its not "legal" to say > 0.9 hours to catch any rounding issues...

And yet, setting the hours to 0 could allow automations to fire seconds after the setup condition instead of around an hour later...

Any thoughts on avoiding the edge case? Or is the "one hour or sometimes about two" as close as the system gets right now?

IN THE MEANTIME I think the documentation needs clarification that this variability exists?

I can see a number of applications for this sort of time condition, but my initial goal was to automate some "nagging" actions - if a ticket is older than an hour, send to this group - if it's older than 2, send to that group... the trouble is that variability could lead us to violate our SLAs.

I understand the reason for not running automations more frequently (i.e. by the minute as some people may want) - as that would bring 60x the database load, and quite a performance hit - however it seems sily to have to resort to API and additional work to make the system perform close to what it seems to be described as.

I view the existing variability as a bug.

Any help upvoting this is appreciated - even if the result is just a stable reliable hourly run (which could still result in tickets "50 minutes" ago waiting for 1:50 for processing.

My suggestion for a real solution

Ideally, the load could be mitigated and performance improved by making a new option - lets call it "Asyncronous Automations" - with those enabled, the default run hourly at some point in the hour could be replaced with something more frequent, but filtered to only tickets modified during a narrow window of time...

Automations might have to be better filtered to only be "seen" once per hour, but closer to that actuao hour.

This seems like it would be less demanding on the system than scanning all tickets through an outside API (which is what people seem to resort to now).

Other suggestions welcome.

My only goal is to arrive at something better than "one to two hours" in terms of performance.

Thanks!

m