429 Errors reported by the trigger in your flow in Power Automate

This morning I was asked about 429 Errors in flows, But rather than 429 errors in actions, this time it was about 429 errors in triggers of a flow.

429 Errors

429 is the number that represents errors due to systems being too busy. In Power Automate you could for example have a flow that uses SharePoint to heavily and then SharePoint protects itself by slowing you down. The calls to SharePoint will then fail with a 429 error status. Power Automate recognise this 429 code and will retry the failing steps until it works.

In my above mentioned post from a while back, I discussed handling 429 errors in actions.

But what do you do if your trigger receives a 429 error? In your flow run history you will see Skipped flow runs. and there isn’t an easy way to recover from this.

When you open the flow run you will see a skipped trigger.

Or sometimes you might get the 429 errors to appear in failed flows showing the red marker on the trigger.

For business critical flows that deal with heavy data processing, this could be quite a big problem. “Is Power Automate not reliable?” is what I hear often asked.

Well it is all about developing your flows in the right way.

Solution 1- queue them up

As with actions receiving 429 errors, with triggers showing this problem.

Within actions you might find that retries are happening and the actions are actually succeeding after some failed attempts.

Or actions might fail after a number of retries.

The error on the right hand side will tell you : “Looks like your flow’s operation is hitting an action limit designed to protect the connector service being called.”

But for triggers this is all not the case. So maybe we should queue up the requests. So let the trigger start and don’t run the actual flow to reduce the number of actions being called. Before you build a complicated queueing system, please look at solution 2 and 3.

Solution 2 – Reduce the number of actions called

One way of solving the issue is to reduce the number of calls that your flow makes. But that may be difficult. We might have to do what we might have to do. There comes a point that your flow just can’t be cleaned up any further.

Solutions 3 – Degree of parallelism

If we zoom in on the Concurrency Control setting …

Now it is possible to do the sums. Looking at the number of actions (+1 for the trigger) running in my flow and the throttling details for the connector that I’m using, I can now decide how many flows I should run at a maximum. Not that you shouldn’t just consider a single flow. Maybe also consider other flows that use the same connector. Once you have configured this degree of parallelism, you will find that there are flow runs with status of Waiting.

These flow runs of Waiting will run at some point but only after there is a slot free to run the flow instance.

When a quieter time appears, the queue of outstanding flows will now be processed.