The flow worked in testing. Then it met real volume — a few hundred SharePoint rows, a folder of files, a Dataverse import — and the run history filled with red: HTTP 429, "Rate limit is exceeded. Try again in 38 seconds." Nothing is broken, exactly. A connector is telling you that you're calling it faster than its allowance permits, and the flow's built-in reaction to that message is what decides whether the run limps to completion or times out. Here is what actually throttles you, how the retry policy behaves under the hood, and the three settings that turn a fragile flow into one that finishes.
What is throttling you
Every connector in Power Automate carries a documented throttle, and it is usually measured per connection per renewal window — not per flow. SharePoint allows 600 API calls per connection per 60 seconds; OneDrive for Business allows only 100 per 60 seconds. Those numbers are the whole story behind most 429s: an Apply to each loop that fires three actions per item, running with concurrency turned up, hits a 100-call limit in seconds. Two things make it worse than it looks. First, the limit is shared by every flow that uses the same connection, so a busy flow elsewhere in the tenant spends your allowance. Second, the 429 counts against nothing but your patience — the platform doesn't drop the request, it queues a retry, and the waiting is where runs go to die.
How the retry policy really behaves
Every action has a Retry policy, and unless someone changed it, it is set to Default. That policy fires automatically when an action returns 408, 429, or any 5xx status — other 4xx responses are treated as permanent failures and never retried. Default is an exponential-backoff policy (the underlying Logic Apps engine documents it as up to four retries at growing intervals), but the intervals it picks can be long: in one documented test, a throttled OneDrive action sat five minutes before its single retry, when the connector's window had reset after sixty seconds. Multiply that pause across a loop and a run that should take two minutes takes an hour, or exceeds its timeout. So the first fix is not "add retries" — the flow is already retrying. The fix is making the retries match the connector's window.
Fix 1: Set the retry policy to match the renewal window
Open the throttled action, click the three dots (…) → Settings, and find Retry policy. You get four choices: Default, None, Fixed interval, and Exponential interval. For a connector with a 60-second renewal period, a Fixed interval with a count of 3 to 5 and an interval of PT1M (one minute — intervals use ISO 8601 duration format, so PT30S is thirty seconds and PT5M is five) means the next attempt lands right after the allowance resets. In the published test above, that single change cut a throttled step from five minutes to one. Use Exponential interval when the downstream service is unpredictable rather than periodically rate-limited: it waits a random, growing interval between a minimum and maximum you set, which stops a burst of retries from re-triggering the same throttle. The engine accepts a retry count of 1 to 90 and a minimum interval of five seconds, so there is plenty of room to tune.
Fix 2: Lower the concurrency that caused it
Retries treat the symptom. The cause is almost always an Apply to each with Concurrency control switched on and the degree of parallelism turned up. Twenty parallel branches, each making a handful of connector calls, exhaust a 100-call-per-minute allowance almost instantly, and every branch then waits on its own retry timer. Open the loop's settings, and either turn concurrency off (items process one at a time, in order) or set the degree of parallelism low enough that branches × calls per branch stays comfortably under the connector's per-minute limit. A loop that runs slower but never throttles finishes sooner than one that sprints into a wall.
Fix 3: Make fewer calls in the first place
The cheapest API call is the one you don't make. Filter at the source with an OData filter query on Get items or List rows so the loop only touches records that need work, instead of retrieving everything and testing each item with a Condition. Move lookups outside the loop and use Filter array or Select on data already in memory — those data operations run inside the flow engine and don't touch the connector's allowance at all. And if several flows share one connection, consider giving the heavy one its own connection so it stops competing for the same window. Fewer calls also means fewer Power Platform request-limit problems, which are a separate ceiling with the same red result.
Honor the Retry-After header when the stakes are high
A 429 response usually carries a Retry-After header stating exactly how many seconds to wait, and the built-in policy doesn't expose it. For a step that truly cannot fail — a payment record, a customer-facing message — a hand-built loop is more precise: wrap the action in a Do until, use Configure run after so the failure branch runs, read the header from the action's outputs, drop it into a Delay, and try again. It's more work, and only worth it where a wasted five-minute wait or a dropped item has a real cost.
Know when not to retry
One caution before you turn retries up everywhere: a retry is a second request, and for actions that create something — send an email, post a Teams message, add a row — a retry after an ambiguous failure can create it twice. Reserve aggressive retry policies for reads and idempotent updates; for create actions, set the policy to None and route failures to a scope that alerts a human, or make the write idempotent with a key check first. The goal isn't a flow that never shows a 429 — at volume, you will see them — but one whose reaction to a 429 is a short, deliberate wait rather than a stall.
Ten minutes, and the red goes away
Set the retry interval to the connector's window, bring the loop's concurrency below the limit, and cut the calls you never needed to make. That's ten minutes in the designer, and it typically converts a flow that fails weekly into one you stop thinking about — which is the point of automating it. If you're weighing whether the workload belongs in Power Automate at all, our comparison of Power Automate vs. Python scripting covers where connector limits stop being a tuning problem and start being a reason to change tools.