Power Automate Error Handling and Retry Design — Preventing 'The Flow Was Working, Then It Just Stopped'

“The aggregation flow that ran every morning had actually been stopped since last week.” “The order-registration flow processed the same data twice, and the ledger ended up with duplicate rows.” We get this kind of consultation request all the time from companies that built a Power Automate flow and put it into operation. It was easy to build — but nobody noticed when it stopped.

If you only ever exercise the happy path, a Power Automate flow will run for hours without incident. But the services it connects to go down temporarily, authentication expires, and unexpected data always shows up sooner or later. A flow that hasn’t designed for “what happens when it fails” quietly piles up failures and, in the worst case, gets automatically turned off after 14 days¹. This article lays out design patterns for error handling robust enough for production: classifying flow failures, the exact specification of the standard retry, a Try-Catch-Finally pattern built from scopes, mechanisms for noticing failures, and re-running and idempotency. Choosing between Power Automate’s overall pieces and error handling on the UI-automation side (desktop flows) is covered in Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling, so this article focuses on a deep dive into cloud flows.

1. The Bottom Line First

• Think of failures in four categories: transient faults, data-caused errors, expired permissions/authentication, and specification changes. The standard retry only solves the first one; the other three need a mechanism for detection and correction².
• The standard retry policy only kicks in when a request times out, or fails with a 408, 429, or 5xx response. The default is exponential backoff, and the count is up to 2 or up to 12, depending on the license tier (performance profile)³¹.
• The basic shape of error handling is Try-Catch-Finally built from scopes and the “Configure run after” setting. The run-after condition is chosen from four states: Succeeded, Failed, Skipped, and TimedOut³⁴.
• Once Catch has handled the failure, finish by recording the run as “Failed” with a Terminate action. Forget this, and the run history shows success, and the failure gets swallowed⁴³.
• The default failure-notification email is limited to “failures with a known fix,” and comes with a 28-day cooldown — it’s a mechanism with too many holes to rely on completely. Treat your own notification from a Catch block as mandatory⁵.
• Run history is visible for only 28 days by default. A flow that keeps failing gets automatically turned off after 14 days. “Not noticing it had stopped until a month later” is entirely possible, by design⁶¹.
• To prepare for re-runs (resubmission) and duplicate triggers, build in an idempotent design that’s safe to run twice (a processed flag, upsert instead of create, trigger conditions) from the very start⁷⁸.

2. How a Flow Fails — Four Categories of Failure

Designing error handling gets much easier once you start from classifying “how it fails.” Microsoft’s own guidance asks you to assume automation can and will fail, anticipating things like maintenance on the connected service, API changes, password changes, and momentary network outages². In practice, thinking in terms of the following four categories determines the response almost automatically.

Of these, the most troublesome one in practice is expired permissions or authentication, because it’s not just the flow’s actions that fail — the trigger itself starts failing. A password change (or expiration) on the credential a connection was using is cited in Microsoft’s own troubleshooting guidance as a typical example of a trigger failing with a 4xx-class error. When the trigger fails, the flow never even starts, so the run history doesn’t get so much as a “Failed” row, and you notice even later⁹. Because a connection is tied to the individual user who created it, an employee’s departure or transfer can also cause a wave of connections to break all at once.

There’s one more thing worth knowing: leaving failures unaddressed gets the flow itself shut off. A flow whose trigger or actions keep failing is automatically turned off after 14 days, and one that keeps getting throttled is likewise turned off after 14 days. A flow that goes 90 days without being triggered can also be turned off, unless its owner holds a premium or capacity license¹. A flow can also end up in a “suspended” state due to a DLP policy violation or repeated failures¹⁰. Some fraction of “the flow was working, and then it just stopped” isn’t a failure at all — it’s this specification at work.

3. Understanding the Standard Retry

Every action in Power Automate (which is built on Azure Logic Apps under the hood) comes with a retry policy built in from the start. Knowing this specification precisely up front lets you judge whether you should add more retry configuration, or whether a retry won’t solve the problem at all.

What Gets Retried, and When

The retry policy kicks in when an action’s (or trigger’s) request times out, or fails with a 408 (Request Timeout), 429 (Too Many Requests / throttling), or 5xx (server error) response³. The default policy is exponential backoff (retrying while stretching the interval out exponentially), and in Power Automate the default count and interval depend on the flow’s performance profile (which effectively comes down to the license tier)¹.

In other words, even with the exact same flow definition, how tenaciously it withstands a transient fault differs depending on the owner’s license. The profile affects not just the retry count but also the daily request-count ceiling, so it’s worth treating the license tier as a first-class part of your design thinking.

You can change the retry policy from an action’s settings. There are four types — Default, None, Fixed Interval, and Exponential Interval — and you can specify the count and interval explicitly. The configuration limits are a maximum of 90 retries, a minimum interval of 5 seconds, and a maximum delay of 1 day³¹. Microsoft’s coding guidelines recommend exponential interval over fixed interval for recovering from a transient fault, so you don’t keep hammering the other side at a short interval and get in the way of its own recovery⁴.

What a Retry Solves, and What It Doesn’t

One thing worth watching for: a retry also consumes request count (Power Platform requests). Every action execution counts toward the request total regardless of success or failure, and so do retry and pagination requests¹. Tuning things toward more retries in response to a 429 can actually make the throttling worse, so before you beef up retries, consider first whether you can simply reduce the number of calls you’re making.

4. The Try-Catch-Finally Pattern — Scopes and Configure Run After

A failure that a retry can’t fix needs to be caught and handled inside the flow. Power Automate has no try-catch syntax as such, but you can build the same structure by combining a Scope with “Configure run after.” This is the standard pattern Microsoft’s own coding guidelines recommend⁴.

The foundation of the whole mechanism is Configure Run After. Every action ends up in one of four states on completion — Succeeded, Failed, Skipped, or TimedOut — and by default, the following action only runs “if the previous action succeeded.” You can change this condition per action, letting you build a branch that runs “if it failed” or “if it timed out”³.

Apply that to a scope, and you get Try-Catch-Finally. A scope rolls up the results of every action it contains into a single overall status, so a structure of “if anything inside the Try scope fails, run the Catch scope” is dramatically easier to maintain than setting a run-after condition on every single action individually³⁴.

flowchart TD
    Trigger[Trigger] --> Try[[Try scope<br/>Put the main processing here]]
    Try -- Success --> Fin
    Try -- Failed / Timed out --> Catch[[Catch scope<br/>Run after: Failed or Timed Out]]
    Catch --> Extract[Use the result function + array filtering<br/>to extract the failed action and its reason]
    Extract --> Notify[Notify the owner via Teams / email<br/>flow name, failed step, error detail, run URL]
    Notify --> Fin[[Finally scope<br/>Run after: Succeeded, Failed, Skipped, and Timed Out, all four]]
    Fin --> Cleanup[Cleanup: update the ledger's status column]
    Cleanup --> Judge{Did it go through Catch?}
    Judge -- Yes --> Term[Terminate<br/>Status: Failed, ending the run]
    Judge -- No --> Done([Normal completion])

There are four points to how you put this together.

• Set the Catch scope’s run-after condition to both “Failed” and “Timed Out.” Remove the default “Succeeded.” Select only Failed, and a timeout on something like an approval-wait or a delayed action slips through undetected³.
• Pull out the details of the failure inside Catch. The result('YourTryScopeName') function returns the results (status, inputs/outputs, error body) of the actions directly inside a scope as an array, so filtering that array down to entries with a status of Failed or TimedOut lets you put the failed action’s name and error message into your notification³⁴. Filter on Failed alone, and the extraction comes back empty whenever Catch was entered via a timeout, dropping the one failed step that actually matters from the notification. It’s also worth pulling the run ID from the workflow() function and building a direct link URL into the run history — it makes investigation dramatically easier⁴.
• Set the Finally scope’s run-after condition to all four states. Put cleanup you always want to run whether it succeeded or failed — deleting temp files, updating the ledger’s status column, and so on — here.
• End a failed run with a Terminate action recording it as “Failed,” as the very last step. This is the single easiest point to forget. If Catch completes normally, the flow run as a whole ends with its last action having succeeded, and the run history records it as “Succeeded.” In other words, if all you do is notify and then stop, the failure becomes invisible in the run history and slips through monitoring and any later tallying. Set Terminate’s status to Failed with an error message before ending, and it stays recorded as a failure in the run history too⁴³. That said, do not place Terminate directly at the end of the Catch scope. Terminate ends the entire run immediately at that point, so the Finally scope that follows never runs, skipping exactly the cleanup you need most when there’s an error. As shown in the diagram, have Catch merely set a failure flag (a variable) and stop at notification, evaluate that flag after passing through Finally’s cleanup, and only then end with Terminate if it failed.

Configure Run After is also the central building block behind an approval flow’s timeout branching (reminders and escalation). The concrete way to build it is covered in Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests.

5. Mechanisms for Noticing Failure — Notification and Visibility

Building error handling means nothing if nobody notices the failure. Design “a mechanism for noticing” in layers, rather than relying on the default notification.

Understanding the Default Failure-Notification Email Correctly

Power Automate does have a mechanism for sending an email notification on failure, but rely on it without knowing the specification, and it’s full of holes. There are two kinds of notification⁵.

• Per-run failure alert: Sent immediately after a run fails, but only when the failure is judged to have “a known fix” — a dropped connection, throttling, a known connector error, and so on. It isn’t sent for a generic action failure. It goes to the owner and co-owners (not to run-only users), and never to admins. On top of that, once one is sent, the same flow enters a 28-day cooldown, during which no additional alert arrives for further failures. Per-run alerts also aren’t enabled by default for every flow; you need to check the flow’s settings⁵.
• Weekly failure digest: A summary of failures across environments is sent once a week. This also includes the generic failures for which no per-run alert was sent⁵.

Beyond that, for certain errors, a “repair tips” email with remediation steps is sent to the owner (and can also be turned off on a per-flow basis)⁷. Put it all together, and the default notification mechanism is one where “you can notice the first dropped connection, but a failure caused by business data, or a second-and-later failure, tends to slip right through.” For any flow that matters, treat your own notification from the Chapter 4 Catch block as mandatory.

Designing the Notification from Catch — When the Notification Itself Fails

Your own notification has design points of its own too.

• Don’t address it to an individual. Send it to one specific person, and it stops reaching anyone the moment they’re out of office or have left the company. Sending it to a shared mailbox or a Teams channel is what the official documentation itself recommends¹⁰.
• Separate the notification path from the main processing. A common accident is a joint failure: the flow fails because its Outlook connection dropped, and the failure notification can’t be sent either, because it uses the same Outlook connection. When the cause is an expired authentication, the notification action sharing that same connection fails right alongside everything else. Using a different connector and connection for the notification than for the main processing — a Teams post, say — or splitting it out into a small, dedicated notification flow you call separately, lowers the risk of this kind of joint failure. Even so, you can’t build “a notification for the notification” indefinitely, so the regular check described next serves as the last line of defense.
• Put everything needed for investigation into the notification. The flow name, the failed action’s name, the error message, a direct link to the run history. Without these, a notification tells you nothing beyond “something failed,” and tends to get ignored⁴.

Visibility and Regular Checks

• Flow checker: Detects errors and warnings in the flow definition before you save. Make it a habit to run this check once after you’ve built something out¹¹.
• Regular checks of the run history: A flow’s run history is displayed for only 28 days by default⁶. A flow included in a solution can retain run-history metadata in Dataverse, but the default retention there is also 28 days, and extending it is an admin-side setting¹². For a production flow, it’s recommended to check roughly once a week, covering not just outright failures but also “cancelled runs” (which can be caused by concurrency control) and “a sudden drop in run count” (a sign the trigger has stopped firing)¹⁰.
• Centralized admin monitoring: To see every single failure — including the ones for which no per-run alert email is sent — the Monitor feature in the Power Platform admin center is the most comprehensive option. It lets you check failure counts and error details per flow or per environment⁵.

For a scheduled flow, you also need to monitor whether it fired at all in the first place. Scheduled-flow design that includes business-day checks and month-end processing is covered in Designing Scheduled Flows in Power Automate — Month-End Processing, Business-Day Checks, and Reminders in Practice.

6. Re-running and Idempotency — Building “It Doesn’t Break Even if It Runs Twice”

Handling a failure doesn’t end with detecting it. You need both the operation of “redoing the part that failed” and a design where “redoing it doesn’t break anything,” as a set.

The Resubmit Specification

A failed run can be redone from the run history via Resubmit. It re-runs with the same trigger data — for a transient fault (500/502, etc.), just resubmit as-is; if the cause was a mistake in the flow definition, fix it, save, and then resubmit, and it re-runs against the corrected definition⁷. From the run-history list, you can resubmit up to 20 runs at once in bulk, which is useful for recovering from a mass failure. For a manually triggered (instant-trigger) flow, you can always resubmit your own runs, but resubmitting a run someone else triggered requires an admin to allow it through a tenant setting¹³.

The important thing here is that resubmitting re-runs the flow from the very beginning. Resubmit a run that failed at step 8 out of 10, and steps 1 through 7, which had already succeeded, run again too. This is exactly where accidents like “the email had already been sent, and it got sent again” or “the ledger ended up with the same row twice” come from.

Idempotency — A Design That’s Safe Even If It Runs Twice

So build in, from the start, a design where running with the same input any number of times produces the same result (idempotent). This is the real core of error design — it protects you not just against resubmission but against duplicate trigger firings and concurrent runs as well.

• Keep a processed flag. Give a ledger such as a SharePoint list a “status” column (Unprocessed / In Progress / Processed); check the status at the top of the flow and stop right there if it’s already processed, and update the status once processing finishes. Do this, and resubmitting no longer causes double processing. This flag only works, though, once you’ve also nailed down the order of the updates. For an external side effect like sending an email or registering something in a core system, update the status to “In Progress” immediately beforehand, run the side effect, and only set it to “Processed” once it’s complete. A run that fails after the side effect but before the flag update is left sitting at “In Progress” — a state where you genuinely don’t know whether the side effect went through. Mechanically resubmitting that row could cause a duplicate send, so exclude “In Progress” rows from automatic re-runs, and instead have a person reconcile them against the actual send or registration result and move them back to “Processed” or “Unprocessed” by hand. The only rows it’s safe to re-run without a second thought are the ones sitting at “Unprocessed.”
• Use “update if it exists, create if it doesn’t” (upsert) instead of unconditional “create.” Look up the existing row by a key that’s guaranteed unique (an order number, an application ID, etc.), and branch into update on a hit or create otherwise. An unconditional “Create item” piles up duplicate rows every single time it re-runs. Put the other way, data without a unique key can’t be made idempotent, so deciding on a key column belongs at the ledger-design stage.
• Stop unwanted firings with trigger conditions. Something like a flow on an “item created or modified” trigger re-firing itself because of its own write-back is exactly the kind of duplicate firing you should stop with trigger conditions, not with a downstream condition branch. An event that doesn’t satisfy the trigger condition never causes a run to happen at all, so it consumes neither a run count nor a request⁸.

One caveat here: a “check, then write” approach like a processed flag or upsert works against a sequential redo like a resubmission, but on its own it isn’t atomic protection. If two duplicate trigger events fire nearly simultaneously, you can get a race where both runs read “Unprocessed” and then both proceed to process it. For a flow where concurrent firings are possible, to prevent duplication reliably, either serialize with concurrency control set to a degree of parallelism of 1 (covered next), or combine it with a mechanism on the storage side that can enforce a unique-key constraint (a database unique constraint, for example) so a duplicate create fails right at write time.

The Tradeoff Between Concurrency Control and Ordering

Alongside double execution, “concurrency” and “ordering” are the other pair of problems. By default, if a large number of events satisfying the trigger condition occur at the same time, the flow runs as many instances as needed, in parallel¹. When multiple runs read and write the same ledger row at the same time, you can get an inconsistency where a stale value gets read and then overwritten — a dirty read¹⁴.

Turn on Concurrency Control in the trigger settings, and you can specify the degree of parallelism from 1 to 100. Set the degree of parallelism to 1, and only one run happens at a time, bringing you closer to processing in order¹¹⁴. This switch comes with a couple of serious caveats, though.

• Once turned on, it can’t be turned back off. The only way to undo it is to delete the trigger and rebuild it¹. Because concurrency control is irreversible, if you apply it, it’s recommended you limit it to a flow with few actions (splitting things out into a child flow if you need to)¹⁴.
• It creates a risk of dropped events. With concurrency control on, the number of runs that can queue up waiting is capped at “10 + the degree of parallelism”; a trigger that arrives while that cap is exceeded gets retried on the connector side, but if the cap stays exceeded for a long stretch, it may never make it to a run at all. The official documentation explicitly states that a flow that needs every single trigger to reliably reach a run should leave concurrency control off¹. If a run history is littered with cancelled runs, this setting can be the cause¹⁰.

In other words, “preserving order” and “not dropping anything” are a tradeoff. Serializing at a degree of parallelism of 1 is effective for low-volume processing where order matters — assigning sequence numbers in a ledger, for instance — but it shouldn’t be used casually for processing that sees a flood of events at peak times. If you strictly need both ordering and completeness at once, you’ve stepped into territory that, as Chapter 8 discusses, should be designed outside Power Automate.

7. A Pre-Production Design Checklist

Before putting a new flow into production, check at least this much.

Twelve items might sound like a lot, but more than half of them are things you only have to think through once, the first time. Conversely, “retrofitting” this onto a flow that already skipped it and went to production tends to never actually get done — compounded by the fear of touching something that’s already running — right up until it causes an incident.

8. How Far to Take It With Power Automate

Push error handling far enough, and you start to see requirements that fall outside Power Automate’s territory. Here’s a rough guide to where to draw the line.

As a rule of thumb, I think of it roughly as: if you can still explain the failure-recovery procedure out loud, it’s Power Automate territory; once you can’t explain it without drawing a diagram, it’s development territory. Work that needs a compensating transaction in particular — registered in Company A’s system, failed in Company B’s, so do you roll back A? — is more complex than a flow’s tidy appearance suggests, and Terminate plus a notification won’t cover it.

9. Summary

“The flow was working, and then it just stopped” is almost never bad luck — it’s almost always a design problem. A flow will fail, eventually, no matter what. Of the four failure categories, a retry only takes care of transient faults; data-caused failures, expired authentication, and specification changes can only be caught by a layered mechanism: Try-Catch to catch them, Terminate to record them, your own notification, and a weekly run-history check. The default failure-notification email is a limited mechanism, conditional and with a 28-day cooldown, and operating on the assumption that it will catch everything is guaranteed to let something slip through.

And the real core of preparing for failure isn’t notification — it’s idempotency. Shape things so “it doesn’t break even if it runs twice,” with a processed flag and upsert, and neither resubmission nor a duplicate trigger is anything to fear anymore — recovery just becomes “pick the failed ones and resubmit.” Conversely, for work that needs a compensating transaction or a strict ordering guarantee, forcing it into Power Automate isn’t the answer; deciding to carve it out into a development effort is cheaper in the long run. The day your flow first goes live is exactly the day to run through this checklist once.

Related Articles

• Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling
• Designing Scheduled Flows in Power Automate — Month-End Processing, Business-Day Checks, and Reminders in Practice
• Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests

Related Consulting Areas

Komura Software LLC handles everything from reviewing error-handling and operational design for Power Automate flows to building out, as a proper system, the ordering guarantees and transaction requirements that a flow alone can’t cover.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

If a Power Automate flow fails, does a notification email get sent automatically?

Only in a limited way. The per-run failure alert email is sent to the owner and co-owners only when the failure is judged to be one with a "known fix" — a dropped connection or throttling, for example — not for a generic action failure. On top of that, once one is sent, the same flow enters a 28-day cooldown during which no additional alerts arrive. Per-run failure alerts also aren't enabled by default for every flow. To reliably notice a failure, we recommend building your own notification into a Teams message or email from a Catch block.

How many times, and at what intervals, does Power Automate's standard retry run?

When an action's request times out, or fails with a 408, 429, or 5xx-series response, it's automatically retried by default, with the interval stretched out exponentially. The count depends on the flow's performance profile (which effectively comes down to the license tier): up to 2 retries on a low profile such as a Microsoft 365 license, and up to 12 retries on a medium or high profile such as Power Automate Premium or a Process license. You can change the retry policy in an action's settings to None, Fixed Interval, or Exponential Interval, and configure the count up to a maximum of 90. Data- or configuration-caused errors like 400 or 404 are not subject to retries.

How do I redo (resubmit) a flow run that failed?

Open the failed run from the run history and choose Resubmit, and it re-runs with the same trigger data. If the cause was a mistake in the flow definition, fix the flow, save it, and then resubmit, and it re-runs using the corrected definition. From the run history list, you can resubmit up to 20 runs at once in bulk. The catch is that resubmitting re-runs the flow from the very beginning, so for a run that had partially succeeded, the steps that already succeeded run again too. You need an idempotent design (a processed flag, writes that prefer update over create) so that the result doesn't break even when something runs twice.

Can a flow get disabled without anyone knowing?

Yes. A flow whose trigger or actions keep failing gets automatically turned off after 14 days. A flow that keeps getting throttled (hitting rate limits) is likewise turned off after 14 days. A flow that hasn't been triggered even once in 90 days can also get turned off, unless the owner holds a premium or capacity license. Because leaving failures unaddressed leads directly to a flow being shut off, it's important to build a mechanism for noticing failures, plus a regular check of the run history (28 days by default), into your operations.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.