The key misunderstanding
In Power Automate Desktop, the Flow timeout setting does not hard‑terminate running UI actions.
Instead:
- The timeout is enforced by the cloud orchestrator
- PAD itself does not interrupt blocking desktop actions once they are executing
- UI automation actions can continue running well past the timeout
So even though your timeout is set to 5 minutes, PAD does not kill the execution when a UI action is stuck.
Why Get details of window waits so long
UI automation actions such as:
- Get details of window
- Focus window
- Wait for window
- Click UI element
internally rely on:
- Continuous retries
- Windows UI Automation APIs
- Session availability checks (especially for RDP)
If:
- The remote desktop session is unavailable
- The window selector never resolves
- The session is disconnected or locked
PAD will keep retrying until an internal max wait expires, which can be 20–30 minutes, regardless of your flow timeout.
That’s why you see:
- Long hangs
- Final error like “The remote desktop was not found”
- Other flows blocked in the queue
Why this started showing up recently (April timeframe)
Your suspicion is very reasonable.
Recent PAD updates increased:
- UI automation resiliency retries
- Session reconnection attempts
- Background window lookup behavior
These changes reduced false negatives, but also made blocking scenarios worse when the target UI never becomes available.
This behavior has been reported more frequently since early April.
Why this blocks other executions
Desktop flows are single‑session, exclusive per machine or host.
While one run is:
- Stuck
- Waiting on UI automation
- Not terminated
No other queued runs can start.
This is expected behavior in PAD’s execution model.
Is this known behavior?
Yes. This is a known limitation, though poorly documented:
- PAD timeouts are not enforced locally
- UI actions are not cancellable once running
- The orchestrator has no way to interrupt a blocked desktop process
This is not a configuration issue on your side.
Practical workarounds (what actually helps)
1. Never rely on flow‑level timeout alone
Treat flow timeout as last‑resort detection, not enforcement.
2. Wrap UI actions with your own timeout logic
Instead of calling Get details of window directly:
- Use a loop with a timestamp
- Check current time vs start time
- Exit manually if exceeded
Example logic:
- Get current time at start
- Retry selector lookup every few seconds
- Exit flow if elapsed time > 2 minutes
This gives you real control.
3. Use “Wait for window” with short timeouts first
Before any UI interaction:
- Add a Wait for window with a very short timeout
- If it fails, exit gracefully
- Do not proceed to blocking actions
4. Detect RDP availability explicitly
Before UI automation:
- Check if the session is unlocked
- Check if expected processes exist
- Validate environment readiness
Fail fast if anything is off.
5. Use a watchdog flow (important for queues)
Create a separate supervisory process that:
- Monitors running executions
- Alerts or restarts stuck sessions
- Prevents long queue starvation
What will NOT help
- Lowering the flow timeout
- Adjusting retry policy in cloud flow
- Queue configuration changes
- Rebuilding selectors alone
None of these interrupt a running desktop action.
Bottom line
- The flow timeout does not stop PAD UI actions
Get details of window can block up to ~30 minutes- This behavior became more visible after recent updates
- It is a known limitation, not a bug in your flow
- You must implement manual timeout and pre‑checks to stay safe
✅ If this answer helped resolve your issue, please mark it as Accepted so it can help others with the same problem.
👍 Feel free to Like the post if you found it useful.
