Why Power Automate approvals time out after 30 days and how the relay pattern of two flows reliably handles long-running approvals.
An approval flow in Power Automate waits patiently as long as the approver doesn't respond, but this patience isn't unlimited. If an approval runs through an extended absence, parental leave, or an investment decision that isn't due until next quarter, the underlying flow run can simply terminate before any response has even come in. For teams that rely on a single continuously running flow, this is an unpleasant blind spot: the request still looks normal in the approver's inbox, but in the background the process is already dead.
This article explains why Power Automate ends approvals after roughly 30 days, what happens somewhat earlier in practice, and how the so-called relay pattern with two separate flows can be used to cleanly handle approvals with an indefinite duration. As of: July 2026.
The cause doesn't lie in the approval feature itself, but in a general runtime limit for cloud flows. According to the limits for automated, scheduled, and instant flows a maximum runtime of 30 days applies to every individual flow run, calculated from the start time of the execution. The documentation states this clearly: the runtime also covers runs with pending steps such as approvals, and after 30 days a timeout occurs for pending steps.
This mainly affects the Start and wait for an approval action, because it blocks the flow run until a response arrives. This very blocking becomes its downfall as soon as the wait time reaches the 30-day limit. At that point, the flow technically has no way to continue running, regardless of whether the approver has overlooked the request or simply hasn't gotten around to it yet.
In the overview of known issues with approvals Microsoft points out a particularity that is more relevant in practice than the documented 30 days: an approval process can reportedly wait 28 days, and if the wait time exceeds these 28 days, the flow fails. It's important to note that this failure only affects the flow run itself. The approval remains visible in the approvals center even though no flow is waiting for it anymore.
This leads to orphaned entries that an approver can theoretically still respond to, without that response ever arriving anywhere. The requester or an environment administrator must manually delete such orphaned approvals from the action center. Anyone who regularly sends approvals with an unclear duration should build this cleanup step firmly into their process maintenance instead of relying on old entries disappearing by themselves.
Microsoft's recommended solution for approvals with a potentially long runtime is splitting the process into two independent flows. According to the guide Create and test an approval workflow with Power Automate the rule is: if a flow runs for longer than 30 days, the approvals should be stored in Microsoft Dataverse. This makes it possible to create flows that react to responses even after the original flow run has long since expired.
Specifically, you use the action Create an approval (v2) instead of the blocking Start and wait for an approval action:
This handover from a sending flow to a waiting flow is the actual relay pattern: instead of a single runner who has to endure the entire distance alone, a second flow takes the baton and isn't bound by any runtime limit of the first.
The known issues mention an effect that many overlook when first building the relay pattern: if the approver responds very quickly, before the flow has even reached the wait action, the flow can get stuck in the waiting phase. Microsoft therefore recommends calling the Create and Wait actions as close together as possible within the flow, or alternatively checking the approval status in Dataverse before the wait action is even started. For a clean relay pattern, it's worth taking a close look at exactly this sequence before putting the flow into production.
Anyone using the prebuilt approvals kit, i.e. the business approval management app, instead of their own flows, already gets part of this safeguard included. According to the approval status reference there is a status called Pending (Timeout): it means that the approver did not respond within the first 30 days and the Power Automate cloud flow run managing this request is automatically restarted. After the restart, the status switches back to Pending, and the request remains valid.
This is a convenient automation, but it only applies within the approvals kit with its Dataverse connection, and not automatically for every self-built flow. Anyone running their own approval flow without this kit has to rebuild the restart mechanism themselves using the two-flow pattern described above.
Anyone who doesn't want to build this pattern alone, or needs to safeguard several approval processes at once, can get support from a specialized provider like NordFlux. You retain control over your process while the technical safeguard against the 30-day limit runs cleanly in the background.
Officially documented is a maximum runtime of 30 days per flow run, but in practice, according to Microsoft, the flow can already fail after 28 days if the wait time exceeds this value. For planning purposes, you should play it safe and calculate with the lower value.
It remains visible and looks normal at first glance, even though no flow is waiting for a response anymore. A response from the approver then goes nowhere, which is why such orphaned entries should be manually removed from the approvals center.
Yes, because the waiting second flow only ever runs for as long as a single wait action allows, and it can be triggered again as needed, as long as the approval information remains stored centrally in Dataverse or another source system. This doesn't lift the 30-day limit of a single run, but makes it irrelevant for the overall process.
No, the automatic restart with the status Pending (Timeout) is a feature of the prebuilt approvals kit with its own Dataverse structure. For an individually built approval flow, you have to replicate this mechanism yourself using the two-flow pattern.
For individual, specific approval processes with their own logic, the self-built two-flow pattern is usually the more suitable and leaner solution. If, on the other hand, several similar approval processes need to be managed consistently across the company, it's worth looking at the approvals kit, because it already comes with timeout handling and status logic.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
Why Power Automate flows shut down after 14 days of sustained throttling, how to recognize it, and how to reactivate the flow cleanly.
Multi-level approval workflow in Power Automate: supervisor, management, delegation and 30-day timeout at a glance.
Lexicon of the most common Power Automate error codes: HTTP status, connector, and timeout errors with solutions.
In practice, things already get tight after 28 days, and a single long-running flow breaks down for approvals. NordFlux implements the relay pattern of two chained flows for you, so even lengthy approval processes complete reliably.
