The scariest automation failure is the one that looks like silence. A flow that used to file the invoices, route the leads or post the weekly report quietly stops, and nobody notices until a person asks where the output went. Power Automate does have rules that turn flows off. They are not hidden, but they are scattered, and most teams only meet them in an email they did not read. This post sorts out which rules exist, which are documented, and the small routine that catches a stopped flow before the business does.
Rule one: sustained throttling
Microsoft's limits and configuration page states that a cloud flow that is consistently throttled for 14 days is turned off. The flow creator and co-creators are emailed when throttling starts and again when the flow is turned off. Throttling here means the flow is hitting request limits, so the fix is usually to slow it down, batch its work or spread it across connections. We cover one common version of this in our guide to the 429 "rate limit is exceeded" error, and the cost side in credit consumption best practices.
Rule two: premium features without a premium license
The same page says flows built with premium features, such as premium connectors, custom connectors, HTTP connectors, an on-premises gateway or business process flows, are turned off after 14 days if the owner does not hold a premium Power Automate license. This one catches people when a flow is built by someone with a trial or a different license tier, then handed to a team that does not have the same entitlement. It also catches flows that were quietly changed: adding a single HTTP action to an otherwise standard flow can change which license it needs.
Rule three: suspension after repeated failures
Microsoft's connection failure troubleshooting guide describes a suspended state, where Power Automate has suspended a flow because of repeated failures. The documented remedy is to open the run history, find the failing action, fix the root cause and turn the flow back on. Some third-party guides put a specific number on it, a 14-day window of continuous failure, but we could not find that exact rule in Microsoft's own documentation, so treat the number as unconfirmed and watch for the suspended status instead of the clock.
The part that is easy to miss: it is only an email
In every case above, the notice goes to the flow's creator and co-creators. If the person who built the flow has left, changed roles or filters those emails into a folder, the first alert never lands. The flow's output stops, and the only visible symptom is the absence of something. Microsoft does say you can turn cloud flows back on at any time, which makes recovery cheap and detection the real problem.
A five-minute routine
1. List the flows that matter. Not every flow, just the ones whose silence would cost money or trust: lead routing, invoicing, approvals, reporting.
2. Name a co-owner. Every critical flow should have at least two owners, one of them a role or shared account that survives staff changes, so a shutdown email has somewhere to land.
3. Check the license against the actions. Open each critical flow and note whether it uses premium, custom or HTTP actions. Confirm the owner's license covers them.
4. Add a heartbeat. Have each critical flow write a line to a log, a list or a channel when it runs, and set a separate scheduled check that complains when the heartbeat is missing. A flow cannot report that it is switched off, so something else has to notice the quiet.
5. Review run history weekly. Repeated failures and throttling warnings are the early signal. Fixing them in the first week is much cheaper than rebuilding trust after a shutdown.
The takeaway
Power Automate will not leave a broken flow running forever, and that is mostly a feature. The risk is the gap between the platform turning a flow off and a human noticing. Two owners, a license check and a heartbeat close that gap for almost no effort. If you are weighing whether a flow belongs in Power Automate at all, our comparison of Power Automate and Python scripting is a good next read.
Sources: Microsoft Learn: limits and configuration, Microsoft Learn: fix connection failures.