Hi @pkour,
Chances are very high that those PAD runs are orphaned; self‑service cancel won’t work after this much time.
If deleting the PAD flow or machine connection doesn’t clear them, may be, I think we need to have Microsoft support to purge them.
Lesson learned: Going forward, please add timeout/retry logic to avoid long‑queued runs.
However, before going to Microsoft Ticket, let's check if we have hammered these areas:
1. Go to the cloud flow that triggered the PAD runs. If the parent cloud flow run is still visible, cancel it there. Sometimes canceling at the parent level clears the child PAD runs.
2. If the parent run is gone or corrupted, the queued PAD runs can’t be canceled individually. In this case, the only way is to delete the entire cloud flow or recreate the PAD connection. This forces the service to drop references to those orphaned runs.
3. Let's check the machine availability - if the machine was offline when those runs queued, they’ll never execute.Hence, please remove or reconfigure the machine group so new runs don’t pile up.
4. Delete the PAD flow or connection - if the queued runs belong to an old PAD flow, deleting/recreating the PAD flow or its machine connection can clear the queue. This forces the service to drop references to those stuck runs.
5. Purge via Admin Center - from Power Platform Admin Center → Environment → Resources → Cloud flows: Try deleting the specific PAD flow run history. If the UI won’t let you cancel, you’ll need backend cleanup.
Note: Sometimes the UI fails, but the CLI can force a cancellation. Run: prefect flow-run cancel <FLOW_RUN_ID>. If you want can read this for some clues.
I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!
