# Power Automate flow failure alerts with Try and Catch scopes

> Power Automate only emails about some failures. Wrap key steps in a Try and Catch scope that emails a link to the failed run, and check the admin alerts.

[Home](https://tenantcraft.ca/)  [Insights](https://tenantcraft.ca/insights)  Power Platform

Govern Oct 14, 2026  8 min read

## Your flow failed on Tuesday and nobody knew: set up alerts

Power Automate only emails you about failures it knows how to fix, and then goes quiet for 28 days. Wrap the steps that matter in a Try and Catch scope that emails you a link to the failed run. Check the admin alerts too, but they need a managed environment and run once a day.

Geri Crroj

Microsoft 365 consultant, Niagara, Ontario

Tested in a live tenant, October 13, 2026

It’s Tuesday, 9:20 PM. A flow called **FIN - Send weekly invoice batch** runs and fails. One step tried to turn the word “twelve” into a number, and it stopped there.

I built that flow to break. I left Microsoft’s failure alerts switched on, and I waited. No email came. The run sat in the flow’s history with a red **Failed** badge, and nobody was told.

Now picture it in production, sending the real invoice batch to accounts payable. It fails on Tuesday. On Friday a supplier calls to ask where their payment is. That call is the first alert anyone gets.

This post fixes that. The fix is about ten minutes per flow, and you only need it on the flows people depend on.

The 5-minute version

1.  **A failed run gets recorded and nothing else.** Run history marks it failed. Nobody gets told unless you set that up.
2.  **Microsoft’s alert emails are narrow.** They only fire for failures with a known fix, and then pause for 28 days per flow.
3.  **Check Repair tips on each flow anyway.** It’s free, and it catches broken connections and throttling.
4.  **For flows that matter, add Try and Catch scopes.** The Catch emails you a link to the exact failed run. Mine arrived the same minute.
5.  **Admin alerts are a once-a-day backstop.** They need a managed environment and they don’t fire in real time.

## Why nobody heard about it

Most people assume Power Automate emails the owner when a flow fails. It does, but only some of the time, and the rules for when are narrow.

Every run of a cloud flow lands in its run history as succeeded, failed or running. You can see it on the flow’s details page, in a card called **28-day run history**. But a record is not a message. The status sits there until someone opens the page.

Microsoft does send two kinds of failure email, and its [own page on failure notifications](https://learn.microsoft.com/en-us/power-automate/understand-flow-failure-notifications) spells out the limits:

| Email | When it’s sent | What it misses |
| --- | --- | --- |
| **Per-run failure alert** | Soon after a run fails, but only when Microsoft finds a known fix: a broken connection, throttling, an AI Builder error, a desktop flow error, or a known connector error | Any general action failure. After one alert, nothing more for that flow during a 28-day cooldown |
| **Weekly failure digest** | Once a week, covering all failures across your environments | Speed. A Tuesday failure can wait days to show up |

Microsoft is open about the gap. If the system can’t name a specific fix, “no per-run alert email is sent. This is by design to ensure that alert emails are actionable.”

My demo failure was exactly that kind: a bad value, with no fix to suggest, so no email. Plenty of real failures look the same. A column got renamed, a file wasn’t there, someone typed text into a number field.

Two more gaps from the same page:

-   Alerts go to the owner and co-owners. **Run-only users** are not included.
-   Alerts never go to environment or tenant admins. Your IT person won’t hear about it either.

## Step 1: check Repair tips on every flow you own

Start here, because it costs nothing. The per-run alerts have a switch on each flow, and Microsoft notes they “aren’t enabled for all flows by default.”

1.  Go to [Power Automate](https://make.powerautomate.com) and open **My flows**.
2.  Select the flow to open its details page.
3.  Look at the command bar for **Repair tips**.

![The Power Automate details page for a flow named FIN - Send weekly invoice batch. The Repair tips off button in the command bar is ringed in red. Below, the 28-day run history card shows one run with a red Test failed badge.](https://tenantcraft.ca/images/fa-01-run-history-repair-tips.png)

My flows > flow details

The label reads Repair tips off when alerts are on. The failed run below it sent no email.

The label confused me. **Repair tips off** is the button that turns them off, so seeing it means alerts are on. When I selected it, Power Automate asked me to confirm:

![A Power Automate dialog titled Stop flow alerts, with the text: Without alerts, you'll need to monitor your flow's health via the Flow dashboard. Confirm and Cancel buttons below.](https://tenantcraft.ca/images/fa-02-stop-flow-alerts.png)

Repair tips off > confirm

The Stop flow alerts dialog. Select Cancel to keep alerts on.

Select **Cancel** to leave them on. On my brand-new test flow they were already on. On older flows, check each one.

Leave Repair tips on, but don’t count on it. It’s the smoke detector that only goes off for certain kinds of smoke.

## Step 2: wrap the work in Try and Catch

This is the fix that catches everything inside the flow. It’s Microsoft’s own [recommended pattern for error handling](https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling): put the real work in one scope, and handle failures in a second scope that only runs when the first one breaks.

A **scope** is a box you can put actions into. If any action inside fails, the whole scope counts as failed. That’s what makes it useful here.

Here’s how I built it, in the new designer:

1.  Open the flow and select **Edit**.
2.  Under the trigger, add a **Scope** action. Rename it **Try**.
3.  Get your existing actions inside **Try**. My flow had one step, so I added it again inside the scope and deleted the old copy.
4.  Below **Try** (not inside it), add a second **Scope**. Rename it **Catch**.
5.  Select **Catch**, open the **Settings** tab, and expand **Try** under **Run after**.
6.  Tick **Has failed** and **Has timed out**. Untick **Is successful**.

![The Power Automate designer with the Catch scope selected. The Settings tab shows Run after, with Try expanded. Has timed out and Has failed are ticked and ringed in red, while Is successful and Is skipped are unticked. On the canvas, Catch sits below Try, joined by an orange and red dotted connector.](https://tenantcraft.ca/images/fa-04-catch-run-after.png)

Catch > Settings > Run after

The dotted orange and red line between the scopes means Catch only runs when Try fails or times out.

Now the Catch scope sleeps on every good run and wakes up on every bad one. It doesn’t matter what broke inside **Try**.

## Step 3: make the Catch email a link to the run

An email that says “something failed” sends you hunting. An email with a link to the exact run takes you straight to the red step.

Inside **Catch**, add **Send an email (V2)** from Office 365 Outlook. I renamed mine **Email me the failed run**. Fill it in like this:

-   **To:** you, plus whoever covers when you’re away.
-   **Subject:** `Flow failed: @{workflow()?['tags']?['flowDisplayName']}`
-   **Body:** the run link, built from the `workflow()` function.

Type this into the body as one line. The designer turns it into an expression:

```
Open the failed run: @{concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'], '/flows/', workflow()?['tags']?['logicAppName'], '/runs/', workflow()?['run']?['name'])}
```

`workflow()` returns facts about the run that’s happening right now: the flow’s name, its environment, and the run ID. Microsoft’s page builds the same link a slightly different way. I used the version above and clicked it from the email. It opened the failed run, with the broken step marked in red.

Last, add a **Terminate** action at the end of **Catch**. Set **Status** to **Failed** and add a short message. The Catch did its job, but the flow still didn’t do its work. Terminate keeps the run marked as failed, so the run history and the weekly digest stay honest.

Then I ran the same broken flow again.

![An Outlook email with the subject Flow failed: FIN - Send weekly invoice batch, sent Tue 10/13/2026 at 9:29 PM. The body reads Open the failed run, followed by a make.powerautomate.com link to the specific run.](https://tenantcraft.ca/images/fa-03-alert-email.png)

Outlook > Inbox

The Catch email, the same minute as the failed run. The link opens that run with the broken step marked.

The run failed at 9:29 PM. The email was in my inbox at 9:29 PM. Same failure as the first run, but this time someone was told.

### Which flows get this treatment

Not all of them. Do it on any flow where a failure means a person waits:

-   It moves money, approvals or invoices.
-   It sends something to a customer or supplier.
-   It runs on a schedule and nobody watches it.
-   Someone would notice it stopped, but only days later.

A flow that tidies up your own inbox can fail quietly. You’ll notice.

## Step 4: the admin backstop, if you have one

If you’re the IT lead, the Power Platform admin center has its own alerts. Microsoft’s [alerts page](https://learn.microsoft.com/en-us/power-platform/admin/monitoring/alerts) covers them under **Monitor** > **Alerts**. They’re useful, but they solve a different problem.

| What you get | The catch |
| --- | --- |
| Alert rules on a metric, like a flow’s success rate, scoped to an environment or one flow | Only on a **managed environment**. You need to be a tenant or environment admin |
| An email to you and up to four other people when a rule trips | Rules are checked every 24 hours, on daily totals. Not real time |
| Up to 50 alert rules turned on per tenant | Plan which flows deserve one |
| A built-in alert for flows under 90% success | Only counts “high-use” flows, meaning 150 or more runs a day. It sends no email, so you have to go and look |

When I opened **Monitor** in my test tenant, both **Alerts** and the **Power Automate** page showed one thing: a prompt to turn on tenant-wide analytics first. So check that before you plan around it.

Admin alerts are good at showing a busy flow that’s slowly getting worse over a week. They won’t tell you about one run that failed at 9:20 PM tonight, which is what the Catch is for.

## What this does not fix

Try and Catch only sees failures inside a run. Some failures never become a run at all.

-   **The trigger never fires.** If the flow is turned off, or the trigger condition never matches, there’s no run to fail. Silence looks exactly like a quiet day. For a scheduled flow, add a monthly reminder to open its run history and confirm it’s still running.
-   **The email connection is what broke.** If the Office 365 Outlook connection in your Catch has expired, the alert can’t send. Repair tips is the thing that covers broken connections, which is one more reason to leave it on.
-   **Nobody reads the inbox.** An alert to one person who’s on holiday is still a silent failure. Send it to two people, or to a shared mailbox.
-   **It doesn’t fix the flow.** It only tells you sooner. You still have to open the run and work out why it broke.

For a large estate (dozens of makers, hundreds of flows), Microsoft also points to sending flow telemetry to Azure Application Insights and alerting from there. That’s an Azure service with its own setup and running costs. It’s worth it once you have more flows than you can wrap by hand. For most offices, a Catch on the ten flows that matter covers it.

## The bottom line

Power Automate records every failure, but it only tells you about the ones it knows how to fix, and then it goes quiet for 28 days. Leave Repair tips on, then add a Try and Catch to every flow a person depends on, with an email that links straight to the failed run. Ten minutes per flow, and the next Tuesday failure reaches you on Tuesday.

Rebuilding old SharePoint workflows in Power Automate? Build the Try and Catch in from the first flow, and the playbook covers the rest of the rebuild.

SharePoint Workflow Rebuild Playbook

PDF · 7 pages · 44 checkpoints

[Email me the PDF](https://tenantcraft.ca/resources/guides/sp2013-workflow-rebuild-playbook)

TWENTY MINUTES

## Tell me what is stuck. I will tell you what it takes.

Same consultant from the first email to the last cutover.

[Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing)

---

_Canonical HTML: https://tenantcraft.ca/insights/power-automate-flow-failure-alerts · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_