Why Did Your Power Automate Flow Suddenly Stop Running With No Error?

Detailed Explanation

A Power Automate flow that was running fine and then goes quiet — no suspension email, no failed runs in its history, nothing that looks like an error — is one of the more frustrating troubleshooting situations in Power Automate, because the platform itself often has nothing to show you. Why was your Power Automate flow suspended or throttled covers the cases where Power Automate actively intervenes and tells you about it; this page covers the opposite situation — a flow that's still technically "On" but has simply stopped being triggered, because something it depends on changed without the flow knowing.

The distinguishing symptom is the run history itself: a suspended or throttled flow shows entries — suspended status, or delayed-but-completing runs. A silently stopped flow usually shows nothing at all for the affected period, because the trigger never fired in the first place.

The Common Causes

An expired or broken connection. Every Power Automate action and trigger runs under a specific connection, tied to a specific user account's credentials. If that account's password changed, its OAuth token expired, its multi-factor authentication settings changed, or the account itself was disabled or removed (most commonly when an employee leaves the company), the connection silently stops working. Power Automate doesn't always surface this clearly — depending on the connector, a broken connection can prevent the trigger from firing at all rather than generating a visible error.

The trigger source was renamed, moved, or deleted. A flow triggered by "a new item in this SharePoint list" or "a new email in this mailbox folder" is watching a specific location. If that list gets renamed, moved to a different site, archived, or deleted — or the mailbox folder is renamed or removed — the trigger has nothing left to watch, and typically stops firing without an explicit error.

A trigger condition silently stopped matching. Flows with a condition on their trigger (only run if a specific field equals a specific value, for example) will simply not fire if the upstream data changes shape — a status field gets renamed, a dropdown's options change, or a form is edited to remove the field the condition checks. The flow isn't broken; it's correctly doing nothing, because the condition it was built around no longer exists as originally configured.

The connection owner left the company or lost access. This deserves separating out from general connection expiry because it's the single most common real-world cause: a flow built and connected under one employee's account keeps running under that same account indefinitely. When that person leaves, their account is typically disabled as part of offboarding — which breaks every connection built under it, often for several flows at once, all silently, all on the same day.

How to Diagnose It

1. Check the flow's own run history first. If it shows genuinely nothing for the period in question — not failed runs, not delayed runs, just an absence — this points to a trigger that never fired, which narrows the cause to a connection or trigger-source problem rather than a logic error inside the flow.
2. Open the flow's connections and check their status. Power Automate's flow details page lists every connection the flow uses; a broken one is usually flagged with a warning icon, though not always immediately.
3. Confirm the trigger source still exists in its original location. Open the SharePoint list, mailbox folder, or file library the flow watches directly and confirm it hasn't been renamed, moved, or deleted since the flow was built.
4. Check who owns each connection, and whether that person still has an active account. This is the fastest way to catch the offboarding-related cause — cross-reference the flow's connection owners against your current employee list.
5. Re-test the trigger condition against current data, if the flow has one, to confirm the condition still matches the shape of the data it's checking.

Fixing It

Reconnect using a current, valid account. If a connection is broken, reconnecting it (ideally to a dedicated service account rather than an individual employee's account, precisely to avoid this recurring at the next departure) restores the flow without needing to rebuild its logic.

Repoint the trigger to the correct location, if the original list, folder, or library moved rather than being deleted outright — most connectors let you simply update the trigger's source location rather than recreating the whole flow.

Review and update the trigger condition if the underlying data's shape changed, adjusting the condition to match the current field names or values.

Build in an ownership handoff step for any business-critical flow, so a departing employee's flows are identified and reconnected under a service account or a remaining team member's credentials before their access is revoked, not discovered broken weeks later.

Things to Consider

• This failure mode is invisible to basic failure alerting. How do you stop an automation from failing silently covers alerting on runs that fail — but a flow that never triggers produces no failed run to alert on. Periodically confirming that a critical flow is actually producing runs is the only way to catch this proactively.
• Connections tied to individual employees are a recurring risk, not a one-off. Any flow built under a personal account will eventually break when that person's account changes or is disabled — using a dedicated service account for business-critical flows removes this failure mode at the source.
• A flow with genuinely no runs for a long stretch isn't necessarily broken. A seasonal or infrequent flow can look identical to a silently broken one; confirm the connection and trigger source are actually intact before assuming failure, rather than reactivating something that was never actually stopped.

Common Mistakes

• Assuming the flow's logic is broken and rebuilding it from scratch. Most silent stops are an external dependency (a connection or trigger source), not a flaw in the flow's own steps — check those first before redesigning anything.
• Not checking who owns each connection until after the person has already left. By the time the flow's failure is noticed, the account may already be fully disabled, making the reconnection more urgent and sometimes requiring IT to temporarily restore access.
• Confusing this with suspension or throttling and looking for a notification that was never going to arrive. Power Automate only notifies for suspension and inactivity — a silently stopped flow generates no such notice, so waiting for one delays diagnosis.
• Fixing the immediate connection without addressing why it was tied to a personal account in the first place. Reconnecting under another individual's credentials just relocates the same risk to the next departure instead of resolving it.