Why Was Your Power Automate Flow Suspended or Throttled?

Detailed Explanation

A Power Automate flow that was working fine and then simply stops — with no error message, no failed-run alert, nothing obviously wrong in the flow's own logic — is one of the more confusing troubleshooting situations the platform produces, because the cause usually isn't the flow itself. It's one of three platform-level mechanisms Power Automate applies automatically, independent of anything wrong with the flow's design: suspension for sustained overuse, throttling for trigger rate limits, and suspension for inactivity.

This is a different failure class from how do you stop an automation from failing silently, which covers the general practice of setting up failure alerts across any automation platform — a flow that's been suspended isn't failing silently in that sense; Power Automate does notify the owner by email. The problem is usually that the notification goes unread, or the owner doesn't recognize which of the three causes applies. It's also distinct from why did your Power Automate flow suddenly stop running with no error — that's the case where the platform never intervenes at all, because an expired connection or a moved trigger source stopped the flow from firing in the first place.

The Three Causes

1. Exceeding your action limit for 14 consecutive days. Every Power Automate license tier includes a daily action-execution allowance. Power Automate doesn't suspend a flow the first day it goes over — it tracks sustained overage, and automatically suspends a flow (or, in some cases, the environment) once its daily limit has been exceeded for 14 consecutive days. This is the platform's way of flagging that a flow's actual usage has permanently outgrown its current license tier rather than reacting to a one-off spike. The fix is either reducing the flow's daily action volume (see do you need a premium Power Automate license for how volume interacts with licensing tiers) or upgrading to a license with a higher allowance.

2. Trigger-rate throttling on a specific connector. Many connectors — especially high-traffic ones like SharePoint, Outlook, or third-party APIs — enforce their own rate limits on how many trigger checks or calls they'll accept in a given period. A flow that polls a connector too frequently, or that's triggered by a burst of events faster than the connector's limit allows, gets throttled: its runs are delayed or queued rather than failing outright, which can look like the flow has become unreliable or slow rather than clearly broken. Throttling limits are set per connector, not platform-wide, so a flow using several connectors can be throttled on one specific step while the rest of the flow runs normally.

3. 90-day inactivity auto-suspension. Under Microsoft's current documented policy, a flow that hasn't run at all — no successful or failed executions — for 90 consecutive days is automatically suspended by Power Automate, regardless of licensing or volume. This most commonly catches flows built for a seasonal or infrequent process (an annual compliance task, a rarely-used approval flow) that simply hasn't had a reason to trigger in three months. The fix here is the simplest of the three: reactivate the flow manually once you notice it's suspended; nothing about its design needs to change.

Diagnosing Which One Applies

1. Check your email for a suspension notice. Power Automate sends the flow owner an email when it suspends a flow, and the notice states the reason — this is the fastest way to distinguish cause 1 or 3 from ordinary failures or throttling.
2. Open the flow's run history in Power Automate. A suspended flow shows a clear "suspended" status at the top of its details page. A throttled flow instead shows runs completing, but noticeably delayed compared to when its trigger event actually occurred.
3. Check the flow's recent action volume against your license tier's daily allowance if the cause looks like sustained overage rather than inactivity — Power Automate's admin center shows usage against plan limits.
4. Confirm the flow genuinely hasn't run in 90 days before assuming inactivity suspension, since a flow with an active but very infrequent trigger (quarterly, for example) can be mistaken for an abandoned one.

Things to Consider

• Suspension is not the same as failing silently. Power Automate does notify the flow owner by email in both the overage and inactivity cases — the practical failure mode is usually that notification going unnoticed, not the platform failing to warn anyone.
• A flow suspended for 14-day overage is a licensing signal, not just a technical glitch. Repeatedly reactivating the same flow without addressing its volume or license tier just delays the same suspension recurring — see do you need a premium Power Automate license for what actually determines a flow's allowance.
• Throttling limits are set per connector and can change. Confirm current rate limits for a specific connector in Microsoft's own documentation before redesigning a flow around an assumed limit, since Microsoft adjusts these over time.
• Seasonal or infrequent flows are the most common victims of 90-day suspension. If your business runs a process only quarterly or annually, build a calendar reminder to check that flow's status rather than relying on remembering it exists.
• Google Workspace's equivalent platform has its own version of this problem. See why did your Google Apps Script trigger stop running for Apps Script's execution quotas and automatic trigger-disabling behavior, if your business runs automations across both ecosystems.

Common Mistakes

• Assuming a suspended flow is broken and rebuilding it from scratch. Suspension preserves the flow's configuration; reactivating it is almost always faster and safer than recreating it.
• Ignoring the suspension notification email because it looks like routine Microsoft noise. These emails state the specific reason for suspension — deleting or ignoring them means troubleshooting from scratch instead of reading the answer Power Automate already gave you.
• Treating throttling as a flow bug and adding retry logic that makes the underlying rate-limit problem worse. Retrying a throttled call more aggressively can push a connector further past its rate limit rather than resolving the delay; spacing out or batching the trigger is usually the better fix.
• Not distinguishing a genuinely broken flow (an expired connection, a changed field) from a suspended one before troubleshooting. These have different causes and different fixes — check the flow's status first rather than assuming the most recent kind of failure you've seen before.