Actions queued over 21 hours with zero jobs; Cancel workflow fails

[ahkuna]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

A push-triggered workflow in a private repository has remained queued for over 21 hours without allocating any jobs.

Observed behavior:

• Created November 11, 2026 at 20:47 UTC; still queued on November 12 after 18:00 UTC.
• The run API reports status queued, conclusion null, attempt 1. The jobs endpoint returns zero jobs.
• Clicking Cancel workflow twice, in separate checks, returned the exact message: "Failed to cancel workflow." No new attempt has started.
• The workflow requests GitHub-hosted ubuntu-24.04. The same workflow configuration succeeded previously.
• GitHub Status showed operational at our latest checks. We cannot confirm the cause.

We have preserved the run and have not deleted it, pushed a replacement, changed workflow configuration, or attempted force-cancel. We have seen similar recent reports in this category, but do not know whether they share the same cause.

Is there a supported recovery path for a queued run with no allocated jobs when normal cancellation fails? Can GitHub staff advise whether an internal queue repair is needed, and how to provide the private run details through an appropriate private channel?

Private repository links, code, and billing details are intentionally omitted. Thank you.

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

[aungzayyanaing]

This is an orphaned run from the November 11 incident, not a problem with your workflow, runner label, or repository configuration.

Your run was created at 20:47 UTC on November 11, a minute before GitHub Status records a resolved incident, "Impact across multiple GitHub products including Actions, Pages, and Copilot," from 20:48 to 21:21 UTC that day. The run record was created just as that incident began, but no jobs were ever allocated to it — which is why the jobs endpoint returns zero jobs, there are no logs, and started_at is null. Status showing "operational" now is consistent with that: the incident is over, but the orphaned run record was left behind.

That also explains why Cancel fails. Cancel has no job or execution to cancel. The UI error "Failed to cancel workflow" is the expected result for a run in this state, not a permissions or configuration problem.

What to try, once:

gh api -X POST repos/<owner>/<repo>/actions/runs/<run_id>/force-cancel

<run_id> is the numeric ID in the run URL. Force-cancel is the API intended for use when normal cancel does not work. If it returns 202, check whether the run moves to cancelled. If it returns 409, stop retrying — that confirms there is no cancellable execution on GitHub's side, and repeated cancel or force-cancel attempts will not change it.

Do not delete the workflow file or the repository to clear this, and do not rely on the run disappearing on its own. Test that Actions is working again with a fresh run (a new push or manual run) instead of waiting on this one — that will not fix the stuck record, but it confirms new runs are unaffected.

The stuck record itself can only be cleared internally, so this needs a private GitHub Support ticket — do not post the private repository or run link here. Open a ticket at support.github.com and include the owner/repository, workflow name, run ID and URL, the creation time (2026-11-11 20:47 UTC), the API result (status: queued, conclusion: null, zero jobs), and the result of the force-cancel attempt above. Support can then check whether an internal queue repair is needed.