What it does

The set of patterns for finding out a flow broke without someone in the business telling you. Ranges from the built-in repair tips email, through a flow that monitors other flows, up to Azure Monitor alert rules over exported telemetry.

Key facts

• Repair tips emails go to flow owners automatically when a cloud flow fails, with a description, a suggested fix, the failure count and a retry link. Owners can turn them off per flow, and many do.
• Try/catch in-flow: a Scope configured to run after the previous Scope has failed, timed out or been skipped, sending a notification and re-throwing. This is the only pattern that catches the failure with full context at the moment it happens.
• A monitoring flow on a schedule, using the Power Automate Management connector to list flows and run history — including "As Admin" actions for admins — then notifying on anything failed since the last check.
• Automation Center is the built-in central hub across Power Automate for execution logs, recommendations and performance metrics.
• Application Insights alerts: cloud flow runs map to the Server Requests signal, so a Failed requests alert fires on run failures. Triggers and actions map to Dependency calls, so Dependency call failures covers action-level errors. Custom log search lets you scope an alert to one environment, flow or action with KQL.
• Application Insights action groups can email, page, or call a webhook — and a webhook into an HTTP-triggered flow is the standard route to Teams, Slack, Pushover or an ITSM tool.
• Managed Environments weekly usage insights email admins a digest of environment activity.
• Admin centre analytics include failed run counts per environment, but not which flows failed.
• The Application Insights telemetry stream isn't lossless; the portal run history is the transactional record.

When to use / skip

Every production flow needs at least one of these, and "the owner gets an email" is not it — owners leave, filter, and turn repair tips off. Start with a try/catch that posts to a Teams channel the team actually reads, because it's cheap, immediate and carries the run URL. Move to Application Insights alerting when the client has an Azure Monitor practice and enough flows that per-flow handling stops scaling. Layer the scheduled monitoring flow on top when you need coverage of flows you didn't build, which in most estates is most of them.

Configuration decisions

• Where alerts land. A Teams channel with an owner beats an inbox; an ITSM ticket beats both if the client runs one.
• Whether alerting is per-flow (try/catch, precise, needs building into every flow) or estate-wide (monitoring flow or Application Insights, broader, less context).
• Whether the alerting mechanism can itself fail silently. A monitoring flow that stops running is worse than no monitoring, so it needs a heartbeat.
• Alert thresholds and grouping, because a throttled flow can generate hundreds of failures in minutes and one noisy incident will get your channel muted.
• Whether "flow succeeded but did the wrong thing" is in scope, which needs business-outcome checks rather than failure alerts.

Gotchas

• Repair tips go to the owner, not to a team. If a service principal owns the flow, nobody receives them at all — which is a real cost of the service principal pattern people forget.
• A try/catch that only notifies and doesn't re-throw makes the run show as Succeeded. Your alerting works and your failure statistics are now fiction.
• Alerting flows built with the same connections as the flows they watch fail in the same incident. Give the watcher its own connection and, ideally, its own owner.
• Application Insights alerts inherit the export's delivery timing, so this isn't a real-time page. Test the actual end-to-end latency before promising a response time.
• Desktop flow failures need their own handling. A cloud flow calling a desktop flow will surface the failure, but an attended run started locally won't reach any of this.
• Alert fatigue kills the whole thing. One badly behaved flow firing every two minutes, and within a week the channel is muted and the outage nobody sees is the next one.

Consultant notes

• Make the error-handling pattern a project standard on day one, with a child flow that does the notifying. Adding it to forty flows retrospectively is a fortnight nobody budgeted.
• Insist on a named recipient team and a channel, not an individual. Alerting into someone's mailbox is how outages survive holidays.
• Pass a correlation ID through every flow and include it in the alert. Without it, the alert says something broke and the person receiving it has nowhere to go.
• Test the alerting by deliberately breaking a flow in UAT. Untested alerting is the most reliably absent thing in a Power Platform handover.
• Set the expectation that alerting covers failures, not wrongness. If the business needs to know that a flow processed the wrong amount, that's a reconciliation control and a separate piece of work.

---

Retest the alert path after any connection, licence or Conditional Access change — the watcher breaks the same way the watched do.