Recurrence trigger not fired at specified frequency
Published Jan 11 2021 01:20 AM 2,016 Views

There might be scenarios noticed where recurrence trigger did not fire at specified frequency. This blog tries to consolidate these recurrence behaviors.


Recurrence trigger:

In some scenarios the start times of recurrences might drift due to factors such as latency during storage calls. The options that can be made use of to make sure that your logic app doesn't miss a recurrence are documented here .


Connection-based trigger:

In addition to the factors explained above for recurrence trigger, recurrences for connection-based triggers like SFTP-SSH, Service Bus etc.  the recurrence schedule isn't the only driver that controls execution, and the time zone only determines the initial start time. Subsequent runs depend on the recurrence schedule, the last trigger execution, and other factors that might cause run times to drift or produce unexpected behavior. For more information, see Recurrence for connection-based triggers.


Recurrences for connection-based triggers might also drift due to long polling nature of the trigger. If suppose, SFTP-SSH recurrence trigger 'When a file is added or modified' fires as per schedule and finds a file, another trigger will run again after 15 seconds to check if there are any more files present. The subsequent next trigger execution time is calculated from the last trigger execution time plus Recurrence interval. Hence, whenever trigger is fired, the immediate 15 seconds trigger is getting executed and altering the subsequent trigger executions.


In the below example, we have a simple logic app where the recurrence trigger checks if a file is added or modified every 3 minutes.




Let's consider the below 3 trigger runs.


Trigger history.PNG


Here, the trigger fired at 6:52:14 PM and found a file.




And then the trigger executed another run in roughly 15 seconds to check for any other pending files.



The subsequent next trigger which you would assume to run at 6:55:14 PM as per schedule has actually run at 6:55:33 PM i.e. 3 minutes after the follow-up trigger run that ended at 6:52:33 PM.




This is by design, contrary to normal assumption. So, every time the trigger fires and finds a file, the next subsequent would drift by roughly 15 seconds and in the long run the trigger recurrence would drift by hours or days from the expected schedule.


If this a concern, you can workaround this behavior by using a the normal recurrence trigger instead of the SFTP-SSH recurrence trigger as shown in the below sample.



Version history
Last update:
‎Jan 11 2021 01:20 AM
Updated by: