GitHub Community
Replies: 5 comments 3 replies
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
|
I'm on the same boat. subscribing just in case. https://api.github.com/repos/OWNER/REPO/actions/runs/RUN\_ID/force-cancel |
|
I'm in the boat also action is stuck for last 7 hours and I can't cancel it. Update now stuck in queue for 10 hours. I thought these queues were going to be cleared hours ago. Run ID: 32984241418 |
|
I’m seeing what appears to be the same issue on a private repository. Affected run details:
Cancellation through the GitHub UI fails with: “Failed to cancel workflow.” I also tried the documented A later replacement run completed successfully, so Actions itself is working again; only this original run remains stranded. The creation time also appears to fall within the same period as the other orphaned/ghost workflow runs reported here following the August 26 Actions incident. Ideally the stranded run needs to be terminalised as |
|
Same issue here on a public repository. Two GitHub Actions runs for the same commit are stuck in Repository:
Affected runs:
For both runs, the jobs API returns: {
"total_count": 0,
"jobs": []
}I also tried force-cancel: but received: This is inconsistent with both the GitHub UI and the workflow run API, which report the runs as The push run was created at The workflow had been working normally before this, and I have not changed the workflow configuration in an attempt to work around the issue. This looks very similar to the reports in this discussion, so I’m adding the run IDs here in case they help with investigation. |
|
same here.... Stuck after the incident |
|
I am experiencing the same orphaned workflow-run state on a private repository. Run ID: 32984524722 Created: 2026-08-26T15:15:25Z Commit: 0565484 Status: queued Conclusion: null Jobs: 0 Cancellation through the GitHub UI fails with Failed to cancel workflow. The CLI and API responses are contradictory: gh run cancel: Cannot cancel a workflow run that is completed Cancel and force-cancel endpoints: HTTP 409 — Cannot cancel a workflow run that has not been queued yet Re-run is rejected because GitHub considers the workflow already running Actions are enabled and the account has 1,703 of 2,000 included Actions minutes remaining. The run appears to have been created during the same August 26 incident window as the other orphaned runs reported here. |
|
Issue still not resolved. I have found no ways to cancel. |
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
💬 Feature/Topic Area
Other
Discussion Details
A pull_request workflow run in a private repository remains permanently queued after the resolved GitHub Actions incident y1t7p9fzrlj2.
Affected run:
The run remained unchanged after the incident was resolved and after the stated delayed-queue recovery period.
One cancellation attempt was made through the GitHub web interface. GitHub returned:
“Failed to cancel workflow.”
The run remains queued with zero jobs. No further cancellation or rerun attempts were made.
A related pull-request check also ended as startup_failure:
The organization still has 1,115 of 2,000 included Actions minutes available, and all affected jobs use standard ubuntu-latest runners.
Is there a supported way to clear these orphaned incident-era runs/checks or have GitHub remove them from the backend?
All reactions