A flow that has run quietly for a year is off. Nobody turned it off, nothing changed, and the run history just stops. Switching it back on works, and then it happens again a few months later, which is the part that tells you this is a policy rather than a fault.
Why a flow nobody touched is suddenly off
Cloud flows that have not been triggered for a sustained period can be turned off automatically. The reasoning is straightforward from Microsoft's side, in that a flow which has not fired in months is usually abandoned rather than dormant, and the platform stops carrying it. The problem is the flows where that assumption is wrong: the annual reconciliation, the quarterly report, the process that only runs when a particular kind of exception turns up.
Those are exactly the flows most likely to be caught, and exactly the ones whose failure is least likely to be noticed until somebody asks where the report went.
The licence behind the flow sets the deadline
This is the detail that turns a vague answer into a date you can put in a calendar, and it is why quoting a single figure at everybody is wrong.
- A free or trial plan gives you 60 days without a successful trigger before the flow is switched off.
- A Power Automate entitlement that comes with a Microsoft 365 plan gives you 90 days.
- Flows owned by a user with a premium standalone plan, such as a per-flow plan or assigned capacity, are not subject to the suspension at all.
That last point is the practical lever. If a flow genuinely needs to sit idle for long stretches and matter when it fires, the licence attached to its owner decides whether it survives. Moving ownership to an account with the right plan is a more durable answer than a reminder in somebody's calendar.
Switching it back on is not always the whole job
The flow turns on, the status says On, and it still does not run. That is usually the connections rather than the flow. A flow authenticates to each service through a connection owned by a person, and those connections can need reauthorising after a long gap, or can be broken outright if the person who made them has been offboarded.
- Open the flow's detail page and look at the connections listed against it, not just the on or off status.
- Fix any connection showing an authorisation warning, signing in again as the account that owns it.
- Run the flow by hand once and read the run history rather than assuming success.
A flow can report On and then fail on its first real trigger, which puts it back on the path to being switched off again.
- Add a second owner while you are in there, so the 30 day warning does not go to one mailbox.
The flow whose owner has left
None of the results for this question deal with the case that most often makes it permanent. When the only owner is offboarded, their connections stop working and nobody else can reauthorise them, so the flow is not recoverable by switching it on. It has to be taken over, and its connections rebuilt under an account that still exists.
This is worth treating as an offboarding step rather than an incident. Any flow with exactly one owner is a flow with a single point of failure, and the inactivity deadline is what eventually surfaces it, usually months after the person left.
Does turning the flow back on reset the clock?
The deadline is measured from the last successful trigger, not from the last time somebody touched the flow, so switching it on without it firing does not buy a fresh period.
Will pending runs finish if a flow is turned off mid-run?
Yes. Runs already in progress continue until they complete.
Can the shutdown be prevented outright?
For flows on a premium standalone plan the suspension does not apply. Otherwise the reliable approach is making sure the flow actually triggers inside the window, or that the warning reaches somebody who will act on it.