← Al Davies, 250 High Street

Fix 429 Too Many Requests in Power Automate

Short answer: a 429 means the service got too many requests and told your flow to wait. Set Apply to each concurrency to 1, add a Delay inside the loop, and set a retry policy on the failing action. If many runs start together, also lower the concurrency on the trigger, and cut the number of requests the flow makes.

What a 429 error means

HTTP status 429 is "Too many requests". It is a throttle. The service is not broken. It is protecting itself from too much traffic.

Microsoft describes this for SharePoint Online: "When usage limits are exceeded, SharePoint Online throttles any further requests from that client for a short period." For requests that an application makes, Microsoft says SharePoint Online "returns HTTP status code 429 ("Too many requests") or 503 ("Server Too Busy"), and the requests will fail."

Microsoft also warns that retrying too fast makes it worse: "Throttled requests count towards usage limits, so failure to honor Retry-After may result in more throttling." Retry-After is a value in the response that says how long to wait. Microsoft's SharePoint page says to honor it. That is why the fixes below slow your flow down instead of pushing harder.

Where the limits come from

Several limits can cause a 429. Which one you hit depends on the connector the failed step uses.

Your flow can hit a connector limit on a quiet day. These limits count requests in a short window. They do not count requests across the whole day.

Rates for four connectors

Each connector page on Microsoft Learn lists a throttling limit. These four are listed:

For Excel, Microsoft's page says of a 429: "If throttling is occurring, it is suggested to add explicit delays around the connector action." Dataverse has its own limits. Open the Dataverse connector page on Microsoft Learn for its numbers.

Signs this is your problem

To see the error, open https://make.powerautomate.com, open the flow, and open the failed run. Click the red step and read the error. Exact names may differ.

Step 1. Find which step is throttled

The failed step is the one to fix. Look at what it does and how often it runs.

  1. Open https://make.powerautomate.com and open the flow.
  2. Open the failed run from the run history.
  3. Find the red step and read its error message.
  4. Count how many times that step ran in that run. A step inside a loop runs once per item.

If the failed step sits inside "Apply to each", the loop is the cause. Go to Step 2. If the failed step is the trigger, or many runs started at once, go to Step 3.

Step 2. Slow the loop

Microsoft's limits page says for Apply to each concurrency: "1 is the default limit. You can change the default to a value between 1 and 50 inclusively." It describes this as the highest number of loop iterations that can run at the same time.

Setting the loop to 1 means one item at a time. It is slower, but it sends fewer requests per second.

  1. Open the "Apply to each" step.
  2. Open its Settings (the three dots menu). Exact names may differ.
  3. Find the concurrency control and set the degree of parallelism to 1.
  4. Save the flow.

Then add a pause. Our advice, not a Microsoft rule: put a Delay action at the end of the loop body so each item waits a few seconds before the next one starts. Start with 1 or 2 seconds and raise it if the 429 returns. A flow that is slow and finishes is better than a fast one that fails.

Step 3. Lower concurrency on the trigger

If a bulk edit starts 300 runs at once, each run sends its own requests at the same time. Concurrency Control on the trigger limits how many runs go together.

Microsoft's limits page says that Concurrency Control "is set in the flow's trigger settings and is off by default." The same page says that when it is on, concurrent runs are "1 to 100 when Concurrency Control is turned on (defaults to 25)". It also warns: "Turning on Concurrency Control can't be undone without deleting and re-adding the trigger."

Because of that warning, do this on a copy of the flow first, or note that you may need to re-add the trigger.

Microsoft has a troubleshooting page for the 429 error, filed under AI Builder. Its fix is: "If this error occurs, decrease the concurrency level of your flow." It shows how: open the trigger's "..." menu, choose Settings, and reduce the degree of parallelism under Concurrency Control. The page uses a SharePoint trigger as its example.

Step 4. Set a retry policy on the action

A retry policy tells an action to try again after a failure. Microsoft's error handling page says: "Exponential retry policies are preferred because they can extend the retry period over time and increase the chances of successfully completing the action."

Microsoft explains that an exponential policy starts with a short interval and grows it each time. Its example: the first retry after one minute, the second after two minutes, the third after four minutes.

  1. Open the action that returns 429.
  2. Open its Settings.
  3. Find Retry policy and choose Exponential.
  4. Set the retry count and the interval. Microsoft says you set "the initial interval, or the time before the first retry, and the maximum retry count".

Microsoft's limits page also lists default retry behavior by performance profile. For Medium and High it says the default policy "sends up to 12 retries at exponentially increasing intervals". For Low it says "up to two retries". Check your own setting before you change it, because the default may already retry.

Microsoft's limits page also gives the limits on retry settings you can change:

For Medium and High profiles, Microsoft says the default policy scales "by seven (7) seconds up to an interval of approximately 1 hour for the last retry". For Low, it scales "by 5 minutes up to an interval of approximately 10 minutes for the last retry".

The service can tell you how long to wait. Microsoft's SharePoint page calls this value Retry-After and says to honor it. A short fixed retry that ignores it adds load. Choose a long enough minimum interval, such as the 5 seconds Microsoft allows as the lowest setting, then raise it if the 429 returns.

A retry policy helps a short burst. It does not fix a flow that sends too many requests all the time. For that, cut the request count (Step 5).

Step 5. Send fewer requests

The cheapest request is the one you never send. Our advice, not a Microsoft rule:

  1. Filter at the source. If you use Get items, add a Filter Query so the flow reads only the rows it needs. See "Power Automate Get items stops at 100 rows: how to get them all".
  2. Do not call the same list again for each row. Read it once before the loop and look up values from that result.
  3. Do not update a row twice. Set all the columns in one Update item action.
  4. Add a trigger condition so the flow starts only for rows that need work. If the flow updates the same list it watches, check that it is not starting itself. See "Power Automate flow keeps running itself over and over".
  5. Run heavy flows at a quiet time. A Recurrence trigger can run a big job at night. Microsoft's SharePoint page says "Throttling and / or performance slowdowns have a higher tendency to occur during peak hours than off-peak hours".

Daily request limits by license

A 429 from a connector is a short-window limit. Power Platform also has a daily request limit for the account that runs the flow. Microsoft's request limits page says, for Power Automate, that "Both successful and failed actions count toward these limits. Retries and requests from pagination also count as action executions."

Microsoft's table of Power Automate request limits per 24 hours:

Microsoft adds that all organizations are in a transition period, during which Premium and seeded license limits are applied per cloud flow instead of per user. Check the live table before you plan around a number. Your admin can see which license your flow uses.

What to avoid

Add an alert so you see failures

Microsoft's error handling page says to use Run after settings, and says: "The Power Automate flow service also sends email alerts to flow owners for common or critical failures like broken connections or throttling issues." You can also add a step that runs only on failure and writes a line to a SharePoint list or sends you a message.

Our advice, not a Microsoft rule: log the item ID and the time when a step fails, so you can run just those items again later.

If the run shows a different error than 429, see "Error: "An action failed. No dependent actions succeeded."".

A check list to follow

  1. Open the failed run and confirm the error is 429.
  2. Find the step that failed and count how many times it ran.
  3. Set "Apply to each" to one item at a time.
  4. Add a Delay action inside the loop.
  5. Lower trigger concurrency if many runs start together.
  6. Set an exponential retry policy on the failing action.
  7. Cut requests: filter, read once, update once.
  8. Re-run a small batch, then a large one.

Honest limits

A 429 can come from a service you do not control, and the limits can change. Microsoft says its displayed limits are default values and may change at any time. Test with a large batch before you trust the flow with real work. Wait a few minutes between large test runs, because a throttle can last for a short period.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Is a 429 error my fault?

It means a limit was exceeded, but the cause can be a flow design that sends many requests at once, and you can change the design. Microsoft's SharePoint page says that throttling limits the number of API calls or operations within a time window.

Will the flow try again on its own?

Microsoft's limits page lists default retry behavior, up to 12 retries for Medium and High profiles and up to two for Low. You can set up to 90 attempts, with a minimum delay of five seconds and a maximum of one day. A retry does not help if the flow keeps sending too many requests.

How many Power Automate requests per 24 hours does my license allow?

Microsoft's request limits page lists 40k per user for Power Automate Premium, 250k per license for Process, and 6k per user for Free and Office 365. It also sets a five-minute limit of 100,000 requests. Failed actions and retries count. Check the live table, since Microsoft says organizations are in a transition period.

What rate does the SharePoint connector throttle at in Power Automate?

Microsoft's SharePoint connector page lists "API calls per connection" as 600 per "60 seconds". Excel Online (Business) lists 100 per 60 seconds, and SFTP-SSH lists 150 per 60 seconds.

How long should my Delay be?

Our advice, not a Microsoft rule: start with 1 or 2 seconds inside the loop, test, and raise it if the 429 returns. Count the calls your loop makes for each item against the 600 per 60 seconds that Microsoft lists for the SharePoint connector.

Sources