Power Automate Error Handling That Actually Works: 429, 404, Timeouts and Retries

Most Power Automate flows are built for the happy path. They run fine in testing, fine for a few weeks in production, and then one morning there are 40 failed runs in the history and a business process quietly stopped working three days ago.

The failures are rarely exotic. A handful of HTTP status codes — 429, 404, 500, 401 — plus timeouts are among the most common causes of failed runs. Each one has a different cause and a different fix, and handling them properly is a modest amount of extra work per flow. Here's a pattern that covers all of them.

Step 0: actually read the error

Before any pattern, a habit: open run history, click the failed run, click the failing action, and read both the inputs and the raw outputs. The status code and message are right there, and they tell you which failure family you're in:

The inputs matter as much as the outputs. Many 404s are solved by looking at the failing action's inputs and noticing the ID it actually used was empty — the dynamic content upstream had resolved to blank.

429: you're being throttled

Connectors, and the services behind them, enforce their own rate limits (the unit and the time window vary), and a 429 is how they tell you that you exceeded one. The classic way to hit them is an Apply to each that calls an action on every item of a list that grew from 50 items to 5,000 — especially once someone has turned concurrency up to make it faster.

Three levers:

1. Concurrency control. On the Apply to each → Settings → Concurrency Control. By default the loop runs its iterations one at a time; if concurrency has been turned on to speed it up (the degree of parallelism can go from 1 to 50), the loop can fire a burst of simultaneous calls at SharePoint or Outlook. In that case, lowering the degree of parallelism (or setting it to 1 for strict sequencing) is usually the fastest way to stop a 429 storm. The trade-off is runtime — which brings us to lever 2.

2. Fewer calls. The best API call is the one you don't make. Filter at the source with an OData Filter Query so the loop only receives rows that need processing, and use batch actions where the connector offers them instead of one call per row.

3. Retry policy with exponential backoff. For the 429s that still get through, configure the action's retry policy (action → Settings → Retry Policy). Example values — tune them to the service you're calling:

{
  "type": "exponential",
  "count": 5,
  "interval": "PT10S",
  "maximumInterval": "PT1H",
  "minimumInterval": "PT10S"
}

Exponential means the wait grows between attempts instead of staying fixed, which is exactly what a throttling service wants from you. Power Automate's default policy is already exponential, but its shape — notably the number of retries — depends on the flow's performance profile, so it isn't tuned to any particular service's rate limit; an explicit policy lets you choose the retry count and the minimum and maximum waits yourself. If a 429 response includes a Retry-After header, honor it: it tells you how long to wait before trying again (usually a number of seconds). The built-in HTTP action can use that header to space its retries (this is documented for the HTTP action in Azure Logic Apps, the engine cloud flows run on); for other actions, don't assume it — make sure your configured intervals aren't shorter than the delay the service asks for.

I go deeper on throttling causes and the delay-inside-loops technique in the 429 Too Many Requests guide.

404 and 500: different bugs, different fixes

These two get lumped together because they're both "the action failed", but they point in opposite directions.

404 = your reference is wrong. The record was deleted, the path points at the wrong site/environment, or a dynamic ID resolved to blank. Guard against it before the action instead of catching it after:

// Condition before the "Get item" action
@not(empty(triggerBody()?['ItemId']))

An empty value in a URL path often ends in a 404. One empty() check upstream is cheaper than any error handler. (empty() accepts strings, arrays and objects; if your ID arrives as a number, compare it with null instead: @not(equals(triggerBody()?['ItemId'], null)).)

500 = the service failed while handling your request. It is often a transient service-side incident — but some services also answer 500 to input they can't handle, such as a malformed JSON body or a null where a value was required. The fix is to read the raw outputs for the underlying message, validate your request body property by property, and — because some 500s really are transient — put a retry policy on the action. Retrying a 404 is pointless (the record won't materialize); retrying a 500 is often exactly right.

Full diagnosis walkthrough for both codes: Power Automate 404 and 500 errors.

Try/catch with Configure Run After

Power Automate has no try/catch keyword, but it has the mechanism: scopes + Configure run after. This is the skeleton worth putting in every non-trivial flow:

Scope: Try
  ├─ (all the real work)
Scope: Catch          ← Run after: "has failed", "has timed out"
  ├─ Compose: error details
  ├─ Post message / send mail to the team
Scope: Finally        ← Run after: succeeded, failed, skipped, timed out (all checked)
  ├─ (cleanup / logging that must always run)
Condition: Try didn't succeed        ← optional, top level of the flow, see below
  └─ Terminate: Failed, with a custom message

Set it up by adding the Catch scope after Try, then opening its Run after setting (new designer: select the scope, then Settings → Run after; classic designer: the three dots → Configure run after). Uncheck is successful and check has failed and has timed out.

Inside the Catch, pull the actual failure details rather than a generic "flow failed" message:

// Compose action — name, status, inputs and outputs of the Try scope's top-level actions
@result('Try')

// Filter array action — keep everything that neither succeeded nor was skipped
From:      @result('Try')
Condition: @and(not(equals(item()?['status'], 'Succeeded')), not(equals(item()?['status'], 'Skipped')))

result('Try') returns the name, status, inputs, outputs, timestamps and tracking IDs of the first-level actions of the scope. It does not drill into deeper nested actions (for example inside a Condition or a Switch). For a top-level action, that is enough to build a notification that says what failed and why (the service's error message is in the action's outputs), not just that something failed. If the failing call sits inside a loop or another nested container, the entry you get is the container itself: call result() on that loop's own name (as in Microsoft's result('For_each') example), or keep the actions you want to report on at the top level of the Try scope.

Filtering is done with the Filter array action; there is no filter() expression function. The condition above deliberately keeps "anything that isn't Succeeded or Skipped" rather than matching one exact string: Microsoft's documentation describes an action stopped by its timeout under more than one status, so this catches Failed, TimedOut and Cancelled alike. A flow that fails loudly with context gets fixed the same day; a flow that fails silently gets discovered a week later by the business.

One subtlety: if the Catch scope runs and handles the failure, the run is marked Succeeded. A run is only marked Failed when a failure isn't handled by a subsequent action. If you'd rather handled errors still show up as failed runs (so they're visible in monitoring), use a Terminate action set to Failed with a custom error message. Keep in mind that Terminate stops the run and skips every remaining action, so don't end the Catch with it if a Finally scope still has to run: put it after the Finally scope, inside a Condition that checks whether Try succeeded, for example @not(equals(actions('Try')?['status'], 'Succeeded')). Keep that Condition + Terminate at the top level of the flow: Terminate is documented as unusable inside Foreach and Until loops (documented for Azure Logic Apps — check that your designer accepts it before nesting it), so don't put it inside an Apply to each. If you'd rather the flow report success once the error is handled, skip the Terminate. Decide deliberately — the default surprises people.

401 / "connection expired": the slow-motion failure

This one deserves its own section because it doesn't fail on day one — it fails months later, after nothing changed in the flow.

Every connector action runs through a stored connection — a saved credential for that connector. When that credential expires, the account password changes, or consent is revoked, every action using that connection typically starts failing with an authentication error, most often a 401. The immediate fix is Power Automate → Connections → find the one showing an error → Fix connection and re-authenticate.

The real fix is structural:

• Critical production flows shouldn't depend on the account of whoever built them. Run them under a dedicated identity: preferably a service principal (Microsoft's recommendation for critical or long-running flows; it is an unlicensed application user, so premium flows it owns need a Process or per-flow license), or otherwise a dedicated service account whose credentials aren't shared between people (Microsoft's FAQ advises against service accounts with shared credentials). Otherwise the flow breaks the day that person changes their password or leaves the company.
• Check connection references when deploying through solutions. When you import a solution, you pick a connection for each connection reference. Without usable connections, the imported flow stays turned off, and if the importer picks their own connections, the flow runs under that account. Connection references are part of the deployment, not an afterthought.
• After fixing a connection, open the flow, check that its actions show a healthy connection, and re-test it. If a trigger still doesn't fire, Microsoft's troubleshooting guide suggests making a small edit to the flow, saving it, reverting the edit and saving again so the trigger is registered again; other options are turning the flow off and on, or removing and re-adding the trigger.

I keep the checklist (including the password-policy angle for service accounts) in the connection expired guide.

Timeouts

Two distinct animals:

• Action timeouts — a downstream call takes too long. On actions that support it (HTTP, connector and webhook actions, for example), you can set an explicit timeout (action → Settings → Action Timeout — labelled just Timeout in some designers — ISO 8601 duration such as PT5M) and combine it with the retry policy. Microsoft describes it as the maximum duration between retries and asynchronous responses for that action; it doesn't change the request timeout of a single request, so it doesn't extend the 2-minute limit on a single synchronous request. Your Catch scope should include has timed out in its run-after conditions — it's easy to configure only has failed and let timeouts slip past your error handling.
• Flow-level limits — a cloud flow run can last up to 30 days, but a single synchronous HTTP request times out after 120 seconds (2 minutes); only asynchronous operations can be configured to wait longer. If a single action routinely brushes its timeout, the fix is architectural (webhooks / polling pattern), not a bigger timeout number.

The checklist

For every production flow:

1. Retry policy (exponential) on actions that call an external service, where the action supports one and repeating the call is safe.
2. Concurrency control tuned on every Apply to each that makes API calls.
3. Guard conditions before actions that take dynamic IDs (empty() checks).
4. Try/Catch scopes with run-after configured for failed and timed out, and a notification that includes result('Try') details.
5. A dedicated owner identity (preferably a service principal, otherwise a non-shared service account) and verified connection references before it ships.

None of this is glamorous, and all of it is the difference between automation people trust and automation people quietly work around.

Most of these guides live in the troubleshooting section of PowerBlocks, the Power Apps YAML component library I maintain — the flow-error write-ups are free, no login.

What's your Catch scope's notification channel — Teams, email, or a log table? And has anyone actually gotten a clean answer out of a bare 500 without reading raw outputs? Comments below.