Microsoft Flow – Getting your flow trigger retries right

After last week’s post where I changed the number of retries  in my triggers I thought that it would be a good to find the best retry settings for Microsoft Flow.

How could we identify the best setting? There are so many things that may happen. To answer this question we need to look at these variables.  In my post about triggers and their limitations I already found out that I’m limited to 600 calls every 60 seconds.

Although in most cases you will find that this is plenty on some cases this is not enough. Well even when this is not enough, you cannot change these numbers. You can however work around the problem.

First of all we need to have a look at how the API calls are spread over time. Imagine if we make 1000 API call per minute then we would look at the total load of API calls needed being higher than the total number of API calls that we need. This would result in us fighting a lost battle.

If the above is your case then  you might have to give up, but if you have the slightest chance of a winning the battle, then you will be interested in this post.

When you look at business processes  you will be able to identify the following type of processes:

  1. light processes – processes that don’t hit any limits and every now and then a process is started.
  2. high peaks with low frequency – these processes exceed the limits, but these peaks are followed by quiet times
  3. high peaks with high frequency – these processes have a heavy load very often and they might not have much quiet time
  4. permanently high during office hours -8 hours every day of high load
  5. permanently high – 24/7 heavy load

Light processes

These processes I’m going to ignore. When you use flow you will be very happy with how it works if you have these kind of processes.

High peaks with low frequency

You will find that you get the 429 errors and these are the once we could deal with by have the trigger retries adjusted. Out of the box Microsoft Flow will retry 4 times and if the system hasn’t recovered by the time it has run out of retries your flow will fail to start.

As the example I’m going to use 100 API calls every other minute. Each peak of 1000 API calls is followed by a quiet period of 1 minute.

In this situation you will find that during the peak minute you could get some 429 errors, especially if your peaks last a bit longer and your recovery time is shorter. However over time you never exceed the total capacity of the connector.

This is where you could consider adjusting the retry period as described in my earlier post. But how should we set the retry?

When you look at your data usage. You will first need to identify the number of API calls per flow. Then identify your recovery period. In the above example this was 2 minutes. Practically you will find that the recovery period will vary during your working day. So find the worst case in your process.

Time to pick up some maths.

R = Recovery time after start of peak

L = Load during the period R.

M = Max APi calls per minute

N = number of retries

T = time between retries.


So in our earlier example:

R = 2 minutes

L = 1000 API calls

M = 600 calls for the SharePoint connector

So we need to make sure that L / R < M


The variables that we can control are N and T.  We now need to make sure that N * T > R

Personally I would set the time between retries to something like 20 seconds. This now means that we need 6 retries to cover the recovery period. There is no harm in setting this to a bit higher just in case the peak is higher than unexpected.

High peaks with high frequency

Looking at the numbers above, you will find that you can do 600 * 60 * 24 calls every day. ( you could even go further and use a week as your base if you find that you are really busy during the week and in the weekends you have your quiet time. Would it now be wise to work with retries every 20 seconds? Probably not.  We can still use the same logic as earlier, however you might want to increase the amount of time between retries. Maybe something like hourly retries would work. This probably very much depends on the speed that you need from Flow.

Permanently high during office hours

With the recovery period set to up to 8 hours. you will find that working with 8 retries 1 hour apart your system will recover overnight.

Permanently high

If you have a need for a permanently high loaded flow. Then please feel free to get in touch. I’d be happy to work together to see if it is possible to resolve this challenge.









Categories:Flow, Microsoft Flow, Office 365, SharePoint Online

Tags: , ,

Please leave a comment or feedback

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: