If an action in a Power Automate cloud flow runs as expected, a HTTP 200 response is received together with any data requested. However, if the action doesn’t complete due to an ‘intermittent failure’ then one of the following status codes is returned:
408: Request Timeout (by default if no response is received after 120 seconds the request times out)
429: Too many requests
500: Internal server error
503: Service Unavailable
522: Connection timed ou
These errors occur infrequently but do happen. They can result from network issues, a heavy load on a server, 2 requests for the same record occurring at the same time and many other reasons
Retry Policies
A retry policy defines what will happen if your flow receives one of the above error codes and is defined for each action by selecting the ellipsis menu on the top right of an action and clicking settings
There are 4 options:
Default
The default retry policy is an exponential interval policy set to retry 4 times
An exponential series of numbers is one that doubles each time, for example, 1, 2, 4, 8 ,16. The value increases very quickly because every step is more than double the sum of all the steps that proceed it
To know the value of a 4 step exponential series you need to know the starting number and frustratingly Microsoft doesn’t tell us what that is! The timing for the default setting isn’t clear nor whether the setting is the same for every action
Consequently, it’s worth changing the Default retry policy and instead use one of the other three options. I’ll look at each in turn
None
The first alternative option is no retry policy. If this is chosen, then if one of the above error codes is returned, the flow continues to run. This may be appropriate, but bear in mind this will cause a problem if any of the following actions require data from the action that failed. For this reason, implementing error handling is useful
Exponential Interval
The purpose of an Exponential Interval retry policy is to reduce the frequency of retires over time. This is to both reduce the frequency of calls on a potentially overloaded network or server and increase the likelihood of the call being successful by giving time for whatever has created the failure to resolve itself
With an Exponential Retry policy, the interval, minimum interval and maximum interval are defined. That sounds confusing. How it works can be explained by the table below and with an example where the interval is 2 seconds, the minimum interval is 4 seconds and the maximum interval is 32 seconds
When the request fails the first time, it retries after 4 seconds. If it fails again then it waits for 4 more seconds before next retry. If it again fails then it waits for another 4 seconds before sending the next request. The fourth retry occurs 8 seconds later, and so on until the maximum interval of 32 seconds is reached. All further request are held at the maximum interval
Up to 90 retires can be specified
If the request is still failing when the maximum number of retries has been reached, then the retries end unsuccessfully
Fixed Interval
A Fixed Interval retry policy is what you’d expect it to be. Retries are made at the desired interval until the number of retries specified have been reached
Up to 90 retires can be specified
Defining Time Intervals
The time intervals are specified using the using the ISO 8601 format in the format: PYMDTHMS where:
P is the duration designator and is always placed at the beginning of the duration
Y is the year designator
M is month
W is week
D is day
T is the time designator that precedes the time components
H is the hour designator
M is minute
S is second
P1Y9M3W5DT12H30M20S represents 1 year, 9 months, 3 weeks, 5 days, 12 hours, 30 minutes & 20 seconds
P2DT12H represents 2 days & 12 hours
PT4M represents 4 minutes
Summary
As mentioned, errors occur infrequently but retries need to be planned for. Up to 90 retries can be requested and depending on the settings, retries can take some time to complete. If a Power App is making the flow request then the app will be ‘hanging’ while Power Automate is waiting to receive a 200 response
Even with a retry policy, there is no guarantee that a successful response will be received so don’t forget to plan for that possible eventuality in your flow. Here’s my recent post on Flow Error Handling explaining how to do that