Unfortunately (and hopefully seldomly!), an action within your Power Automate flow could produce an error. We see several posts on the community forums, our support service and general conversations with customers who report that errors take forever to return or that a Flow becomes unresponsive and “times out”. So this is for all of you who are sick of running into the Power Automate Retry Policy.
Note: I have used Encodian actions (and forced the errors with bad data) for this post, but this post applies to all connectors and actions across Power Automate.
Consider the following Flow, which appears to have timed out:
The ‘Flow run timed out. Please try again.‘ error message is misleading. The Flow has not timed out. It is still executing. The error message means the user interface has ‘Timed Out’, but the actual Flow is still executing, which you can see in the run history of the Flow:
Eventually, the Flow will complete and fail:
Now, if you open the execution from your run history, you’ll see that the action appears to have taken 20 minutes to fail!
But if you click on the action, you’ll see that it has failed multiple times, and the duration is extensive because the default Power Automate ‘Retry Policy‘ has not been changed:
The Power Automate ‘Retry Policy‘ controls how many times to retry when an action fails, returning a 408, 429 or 5** HTTP status code. This can be useful to assure your Flow does not fail if an intermittent issue occurs, but if left unchanged during flow development or troubleshooting, it will result in a lot of lost time!
The simple fix is to disable the retry policy, which can be done as follows:
Now, after completing this change to the ‘Retry Policy‘ and re-executing the Flow, the action fails in 2 seconds and not 20 minutes:
Disabling the ‘Retry Policy‘ for a production scenario is not a great idea as there will be intermittent issues where the policy prevents a complete failure of your flow execution. You may wish to create a custom policy to control retry counts and intervals.
You may have noticed that the ‘Retry Policy‘ description states the default policy will retry four times:
But this has been changed eight times, and this description simply hasn’t been updated!:
If the default policy (8 executions) takes too long time to fail, you may wish to configure your custom policy. The following configuration performs three retries with a fixed interval of five seconds:
The following configuration performs three retries on an exponential interval between twenty seconds and five minutes:
The internal format adheres to the ISO 8601 duration format.
We hope you’ve found this guide useful. As ever, please share any feedback or comments, all welcome!
Managing Director
