How to set up error handling in Power Automate

Power Automate auto-disables flows after ~14 days of consecutive failures. This is to prevent runaway failures from consuming resources.

Default behavior: failure email is sent to the flow owner. If the owner ignores it (or has email filtering), it goes unnoticed.

For business-critical flows, default behavior is dangerous. You need active monitoring, not passive emails.

The 14-day auto-disable is recoverable: re-enable the flow + fix the underlying issue. But during the 14 days, no work happens.

My Flows → click flow → Settings (gear icon or "..." menu) → "Send notification email if flow fails."

Default is OFF for many flow templates. Turn it ON for every business-critical flow.

Add the owner + at least one teammate as notification recipient. Single-recipient notifications are a single point of failure (vacation, account suspension, email filters).

For higher reliability: pipe notifications to a Teams channel using the next step.

Right-click any action → "Configure run after."

Default is "is successful" (run only after upstream success). Other options: "has failed," "is skipped," "has timed out."

Pattern: build a "Catch" action with Run After = "has failed" — it only runs when the upstream action fails.

The Catch action can: post to Teams with the error details, write to a SharePoint error log, or trigger a separate cleanup flow.

Pattern: build a "Finally" action with Run After = "is successful" AND "has failed" — it always runs regardless of outcome.

Create a new flow: "Error Handler — Central Logger."

Trigger: "When an HTTP request is received" (HTTP-triggered flow).

Actions:

- Post to a Teams channel with: flow name, failed step, error details, timestamp.

- Append to a SharePoint "Flow Errors" list for persistent log.

In each business flow: add a Catch action that calls this Error Handler via HTTP POST with error details.

One place to monitor errors across all flows. Add/remove notification channels in one place.

Right-click any action → "Settings" → "Retry Policy."

Default: 4 retries with exponential backoff (5s, 15s, 45s, 135s). For most APIs, this is sufficient.

For known-flaky integrations: increase to 10 retries with longer initial backoff.

For idempotent operations (read, find): always enable retries.

For non-idempotent operations (create, charge, send): be cautious — retrying a "Create" that already succeeded creates duplicates. Use "Find or Create" patterns or disable retries.

Create a flow: "Daily Power Automate Health Digest."

Schedule: every day at 9 AM.

Use Power Automate Management connector → "List Flows" and "Get Flow Run History."

Filter: flows that failed or were auto-disabled in the last 24 hours.

Post to Teams: "Yesterday: 142 runs, 5 failures across 3 flows. 1 flow auto-disabled: [flow name] — see [link to flow]."

This catches the auto-disable failure mode that per-flow notifications might miss.

Calendar reminder: weekly 15-minute review of the Flow Errors log + last week of daily digests.

Triage: real failures need fixing. Transient API blips with successful retries are OK. Known-flaky integrations need either longer retries or vendor escalation.

For flows that fail repeatedly (3+ failures/week): investigate root cause. Common: stale credentials, schema drift, vendor API changes.

Discipline matters — without weekly review, the alert channel becomes noise and real failures hide.