Looking closely at those times, and at how the scheduling works, I’m going to guess that it’s an issue on our side with rounding in the timing/executing system. Basically, it works by finding the next time that it should run, subtracting the current time, and telling the system to wait that long. As soon as the group runs, it is asked to calculate the next execution time.
Looking at your timestamps, we see some rows coming in at 23:56:59, not 57:00. IF it ran then, and then immediately calculated the time, it would say, “hey, run again in 1 second- at 57:00”, which is in line with what we see.
I’ll have to look closely at how to handle this. If nothing else, this scheduling system only offers resolution to the minute, so if you’re specifying an exact time, there really shouldn’t be a way for it to run more than once a minute.
As a work around, I think you can do the following: Specify a range (“23:57-23:58”), and then set the rate for something larger than the range, like 5 minutes. When you specify a range, you can then specify a rate, and this works by adding the rate on to the last execution, until it’s outside the range. Then, it looks to the start of the next range (which can be the next day). In this case, your rate is large, so it will always forward over to 23:57 the next day. If it happens to run at 22:59, no problem, because 5 minutes will still be outside of the range.
Hope this helps,