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.
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 spells out the limits:
| 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.”
- Go to Power Automate and open My flows.
- Select the flow to open its details page.
- Look at the command bar for Repair tips.
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:
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: 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:
- Open the flow and select Edit.
- Under the trigger, add a Scope action. Rename it Try.
- Get your existing actions inside Try. My flow had one step, so I added it again inside the scope and deleted the old copy.
- Below Try (not inside it), add a second Scope. Rename it Catch.
- Select Catch, open the Settings tab, and expand Try under Run after.
- Tick Has failed and Has timed out. Untick Is successful.
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.
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 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.