Cannot cancel a workflow run that is completed + HTTP 409 "Cannot cancel a workflow run that has not been queued yet" + HTTP 403 "Could not delete the workflow run"

[geozhuk]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Six workflow runs in a private repository were created during the GitHub Actions incident of 11 November 2026 (resolved 21:21 UTC) and have stayed in "queued" ever since.

State of each run (REST API): status "queued", conclusion null, run_attempt 1, zero jobs, updated_at equal to created_at (20:42-20:43 UTC, 11 November).

Run IDs: 43097612289, 43097612291, 43097676506, 43097676459, 43097690559, 43097690509

What I tried:

• gh run cancel -> "Cannot cancel a workflow run that is completed"
• POST force-cancel -> HTTP 409 "Cannot cancel a workflow run that has not been queued yet"
• gh run delete -> HTTP 403 "Could not delete the workflow run"

New runs in the same repository start and complete normally, and the workflows have no concurrency group, so nothing is blocked. The runs only remain as stale entries.

Could GitHub staff clear or close these six runs? I can share the repository name privately.

[github-actions[bot]]

💬 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 ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

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. ⭐

[aesharhel-bot]

Thanks for documenting all six affected runs and the API responses.

Since new runs are completing normally, I'm curious about the operational impact of keeping these six stale runs in the repository.

Do they create any issues for your team, such as confusing CI status, affecting reporting or auditing, or requiring manual investigation? Or are they mainly historical entries that you would simply like GitHub to clean up?

I'm researching GitHub Actions reliability and trying to understand which problems create meaningful operational costs for engineering teams.

Thanks again!

[Srikanthkesani2]

These stale runs mainly create confusion in the Actions history and make CI monitoring less reliable. They also require unnecessary manual investigation. A way for repository owners to clean up or close such orphaned runs would be very helpful.

[aesharhel-bot]

Thanks for clarifying. The impact on CI monitoring and the additional manual investigation are particularly interesting. I'm curious: approximately how much time does your team spend investigating these stale runs, and have you experienced this issue repeatedly across different workflows or repositories? I'm researching how engineering teams manage GitHub Actions reliability and reduce the time spent investigating abnormal workflow states. Thanks again for sharing your experience. GitHub Actions reliability and reduce the time spent investigating abnormal workflow states. Thanks again for sharing your experience. ‫في الخميس، 12 نوفمبر 2026 في 7:09 م تمت كتابة ما يلي بواسطة ‪Kesani Srikanth Reddy‬‏ ***@***.***‬‏>:‬

…

These stale runs mainly create confusion in the Actions history and make CI monitoring less reliable. They also require unnecessary manual investigation. A way for repository owners to clean up or close such orphaned runs would be very helpful. — Reply to this email directly, view it on GitHub <#212905?email_source=notifications&email_token=CUSS3KE33UFLBLQGTFCWCR35YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19570417>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KDL2DKAB7FOBTEFPWL5YXVDXAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSHEYDSNRWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFMSWN4COG3XJ5XH2D5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KD4VJFPQJ3JDI22BVT5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

Thanks for sharing your experience. I have two quick follow-up questions: 1. How often does your team experience these stale or orphaned workflow runs? Has this happened across multiple workflows or repositories? 2. Approximately how much engineering time does your team spend investigating and dealing with these issues? I'm trying to understand how frequently these problems occur and their actual impact on engineering teams. Thanks again for your help! ‫في الخميس، 12 نوفمبر 2026 في 7:09 م تمت كتابة ما يلي بواسطة ‪Kesani Srikanth Reddy‬‏ ***@***.***‬‏>:‬

…

These stale runs mainly create confusion in the Actions history and make CI monitoring less reliable. They also require unnecessary manual investigation. A way for repository owners to clean up or close such orphaned runs would be very helpful. — Reply to this email directly, view it on GitHub <#212905?email_source=notifications&email_token=CUSS3KE33UFLBLQGTFCWCR35YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19570417>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KDL2DKAB7FOBTEFPWL5YXVDXAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSHEYDSNRWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFMSWN4COG3XJ5XH2D5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KD4VJFPQJ3JDI22BVT5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

Hi! I'm currently researching how engineering teams use GitHub Actions, particularly around CI/CD costs, wasted workflow runs, and reliability issues. I'd really appreciate your perspective on a few questions: 1. What is the biggest challenge your team faces when using GitHub Actions? 2. How often do you experience unexpected CI costs, wasted workflow runs, or workflow reliability issues? 3. Can you describe the last time one of these problems occurred and how much time or money it cost your team? 4. How does your team currently monitor GitHub Actions costs, identify wasted CI minutes, and detect workflow failures? Do you use any paid tools? 5. If a tool could identify unnecessary workflow usage, explain cost increases, and detect reliability issues early, would your company consider paying for it? Why or why not? 6. What monthly price would your company realistically consider for a tool like this? Would your team be willing to test an early prototype? Your honest feedback would be extremely valuable to my research, even if your answer is that your team doesn't need such a tool. Thank you for your time! ‫في الخميس، 12 نوفمبر 2026 في 7:17 م تمت كتابة ما يلي بواسطة ‪AESHA RHEL‬‏ ***@***.***‬‏>:‬

…

Thanks for sharing your experience. I have two quick follow-up questions: 1. How often does your team experience these stale or orphaned workflow runs? Has this happened across multiple workflows or repositories? 2. Approximately how much engineering time does your team spend investigating and dealing with these issues? I'm trying to understand how frequently these problems occur and their actual impact on engineering teams. Thanks again for your help! ‫في الخميس، 12 نوفمبر 2026 في 7:09 م تمت كتابة ما يلي بواسطة ‪Kesani Srikanth Reddy‬‏ ***@***.***‬‏>:‬ > These stale runs mainly create confusion in the Actions history and make > CI monitoring less reliable. They also require unnecessary manual > investigation. A way for repository owners to clean up or close such > orphaned runs would be very helpful. > > — > Reply to this email directly, view it on GitHub > <#212905?email_source=notifications&email_token=CUSS3KE33UFLBLQGTFCWCR35YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19570417>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/CUSS3KDL2DKAB7FOBTEFPWL5YXVDXAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSHEYDSNRWUF3AE> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/CUSS3KFMSWN4COG3XJ5XH2D5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> > and Android > <https://github.com/notifications/mobile/android/CUSS3KD4VJFPQJ3JDI22BVT5YXVDXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YDIMJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. > Download it today! > You are receiving this because you commented.Message ID: > ***@***.*** > com> >

[aesharhel-bot]

Hi! I'm currently researching a SaaS product concept called *GitHub Actions Cost & Reliability Intelligence*. The goal is to help engineering teams monitor GitHub Actions costs, identify wasted CI minutes, detect stuck or missed workflow runs, and receive actionable recommendations to improve cost efficiency and reliability. I'd really appreciate your feedback on these 5 questions: *1.* What are the biggest challenges your team faces when managing GitHub Actions costs and workflow reliability? *2.* How much do these problems affect your team in terms of wasted money, engineering time, delayed deployments, or interrupted workflows? *3. * How does your team currently monitor and manage these problems? Do you use any dedicated or paid tools? *4.* If a tool could help your team reduce CI costs, identify wasted minutes, detect workflow failures earlier, and save engineering time, would your company consider paying for it? Why or why not? *5.* What monthly price would your company consider reasonable for a tool like this? Would your team be willing to test an early version if it addressed your needs? Your honest feedback would be extremely valuable to my research. Even if your company wouldn't pay for such a tool, I'd appreciate knowing why. Thank you for your time! ‫في الجمعة، 13 نوفمبر 2026 في 12:02 ص تمت كتابة ما يلي بواسطة ‪Aung Zay Ya Naing‬‏ ***@***.***‬‏>:‬

…

These six runs are in a corrupted server-side state left over from the 11 November incident, and that is why the three calls disagree with each other — and why none of them can fix it from your side. - The REST API reports each run as status: "queued", conclusion: null, with zero jobs and updated_at equal to created_at. That is a run record that was created but never got a job attached, so it never actually started. - gh run cancel says the run is "completed", because the cancel path reads a different, already-closed state for the same run. Cancel only works on a run that is queued or in progress, so it refuses. - Force-cancel (POST /repos/{owner}/{repo}/actions/runs/{run_id}/force-cancel) returns 409 "has not been queued yet" for the same reason in reverse: it expects a run that is queued and waiting to be picked up, but the run's internal state says it was never queued. - gh run delete returns 403 "Could not delete the workflow run" because delete expects a run in a clean completed state, and this run is neither cleanly queued nor cleanly completed in GitHub's records. The 403 here is about the run's state, not your access — the same credentials reach the API fine, and new runs in the same repository start and complete normally. So there is no sequence of cancel, force-cancel, or delete calls that will clear these runs: each endpoint fails because it assumes a state the run is not in, and the run's state is inconsistent across those endpoints. The only way to clear them is GitHub Support, exactly as you asked. Open a ticket at help.github.com, give the six run IDs (43097612289, 43097612291, 43097676506, 43097676459, 43097690559, 43097690509) and the repository name privately, and note that cancel, force-cancel, and delete all fail with the errors above. Support can remove the stale run records from GitHub's side. Until then, the runs are cosmetic only: with zero jobs and no concurrency group, they are not holding a runner, not blocking later runs, and not consuming minutes. They only pollute the Actions history and any monitoring that counts queued runs, which is the impact Srikanthkesani2 described. — Reply to this email directly, view it on GitHub <#212905?email_source=notifications&email_token=CUSS3KH2GV4LY3ZHNN4DGRT5YYXP5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG42TQMZVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19575835>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KGDNNLSZOJKJHN33SL5YYXP5AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSHEYDSNRWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFWQTP5DFWEXMLRPO35YYXP5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG42TQMZVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KEEPAPPVPCPKM43ZFD5YYXP5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG42TQMZVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>