The short version: Power Automate switches a cloud flow off by itself when it has failed continuously for 14 days, or stayed throttled for 14 days, or when it has not been triggered for 90 days. Only the flow's owners and co-owners are emailed, never the admin. Fix it with a failure alert, tighter triggers and a named second owner.
The rules Microsoft documents
| What the flow does | Limit | What happens |
|---|---|---|
| Trigger or actions fail continuously | 14 days | The flow is turned off |
| Consistently throttled | 14 days | The flow is turned off; Microsoft's advice is a Power Automate Process licence for that flow |
| Consistently above the throughput limits | 14 days | The flow is turned off; editing the flow resets the count, because the limits apply to one version |
| Never triggered | 90 days | The flow might be turned off; owners and co-owners are notified 30 days before |
One exception on the 90-day rule: flows owned by users with premium licences, or with a capacity licence such as Power Automate Process, are not subject to it. Source: Microsoft Learn, Limits of automated, scheduled, and instant flows, retention limits and throughput limits, read on 30 September 2026. A flow that breaks a data loss prevention policy is also suspended, and a suspended flow shows as Suspended in the maker portal and admin centre.
What counts as failing
Microsoft's wording is that the trigger or actions "fail continuously". It publishes no failure percentage, and I have not found one, so I would not plan around a number. Treat any flow that has failed on every run for a fortnight as already on its way off. Behind the scenes the suspension reasons are named AlwaysFailingDetected, AllActionsFailingDetected, ApiCallOverageDetected, NeverTriggeringDetected and two billing reasons. An admin can read them through the Power Automate Management connector or PowerShell, where the flow shows State as Suspended with a reason and a time.
What the email says, and who never sees it
- Per-run failure alert. Sent shortly after a run fails when Power Automate recognises a known, fixable cause such as a broken connection or a throttled action. Its sections are the time the flow first failed, what happened, how to fix it, and troubleshooting tips with the failure count and a retry link.
- Only for fixable causes. If the cause is not recognised, no alert is sent, by design.
- One per 28 days. After an alert there is a 28-day cooldown before the same flow can send another.
- Owners and co-owners only. Run-only users are not included, and failure alerts are never sent to environment or tenant admins. If the person who built the flow has left, the email goes to a mailbox nobody reads.
- Not on for every flow by default. Microsoft says per-run alerts are not enabled for all flows, so check the flow's settings.
- A weekly digest of all failures also exists, sent regardless of cause.
Source: Microsoft Learn, Understand flow failure notifications and Troubleshoot a cloud flow, read on 30 September 2026.
How to stop it happening
- Add your own failure alert. In the flow, add a parallel branch after the action most likely to fail, set Configure run after to has failed only, and send an email or Teams message to a shared mailbox. It arrives within minutes, not weeks.
- Name a second owner. Add a co-owner who is not the builder, so the Microsoft emails have somewhere to land when someone leaves.
- Cut the requests. Add trigger conditions, filter at the source instead of looping over every row, and remove retries you do not need. Every action counts, including compose and variables.
- Check the run history weekly for failed and cancelled runs and for a sudden drop in run count, which means the trigger stopped firing.
- Use a connection that outlives a person. Microsoft suggests service principal connections for key connectors, since they do not expire when someone changes a password or leaves. The people side of this is in the flow that broke the day its builder left.
- Only buy capacity when the cause is throttling. A Process licence for one flow is NZ$242.70 a month on Microsoft's NZ list, which is rarely the right fix for a small firm; reducing requests usually is. The limits are set out in Power Automate limits and throttling and the licence maths in what Power Automate actually costs.
If a flow has already been switched off, open its run history, fix the failing action, then turn it back on. A polling flow, such as a scheduled or recurrence one, processes the events it missed when it comes back on, but a webhook flow only sees new events, so decide what to do about the gap first.
If a flow has stopped and you do not yet know why, the full checklist is in why did my flow just stop running.
Common questions
Why did my Power Automate flow turn itself off?
Almost always one of three documented rules: the trigger or actions failed continuously for 14 days, the flow was consistently throttled or above its limits for 14 days, or it was never triggered for 90 days. A data loss prevention policy violation also suspends a flow. The run history and the flow's status show Suspended and the failing action.
How long before Power Automate turns off a failing flow?
14 days of continuous failure or consistent throttling. For a flow that is simply never triggered the period is 90 days, with owners and co-owners notified 30 days before, and flows owned by premium-licensed users are exempt from that rule. Microsoft does not publish a failure percentage.
Who gets the email when a flow fails?
Only the flow's owner and co-owners. Personal flows email the creator, shared flows email all co-owners, and run-only users, environment admins and tenant admins are never sent per-run failure alerts. After one alert there is a 28-day cooldown for that flow.
How do I turn a suspended flow back on?
Open the flow in make.powerautomate.com, read the run history to find the failing action, fix the cause, then turn the flow on. If it was throttled, reduce its requests first or assign a Power Automate Process licence, or it will be suspended again.
How do I get warned before a flow is switched off?
Add a run-after branch set to has failed that emails a shared mailbox, add a co-owner who is not the builder, check that failure alerts are enabled in the flow's settings, and look at the run history weekly. Do not rely on Microsoft's emails alone.
A flow nobody is watching
Tell me which flows the business depends on. One free 30-minute call and you get a list of what is at risk and who should own it. A second opinion on your existing flows is the short version.