Workflow runs stuck in "queued" with zero jobs, cannot be cancelled (409 via API, 422 via web UI)

[TRGamer-tech]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Repository: TRGamer-tech/Rezeptli (public)
Workflow: .github/workflows/index-bauen.yml ("Rezeptindex", Pages deploy)

What happens
Two manually dispatched (workflow_dispatch) runs on main (commit 4ee1e94d81aaa54baad5e87fe2c4c924fbba3960) stay in status "queued" and never create a single job:

• Run #69, id 40224204473, created 2026-10-25 19:03 UTC: https://github.com/TRGamer-tech/Rezeptli/actions/runs/40224204473
• Run #70, id 40225569392, created 2026-10-25 19:20 UTC: https://github.com/TRGamer-tech/Rezeptli/actions/runs/40225569392

The jobs endpoint returns total_count 0 for both, still the case at 19:44 UTC (40+ minutes).

Cancel fails

• REST API: POST /actions/runs/40224204473/cancel returns 409 "Cannot cancel a workflow run that has not been queued yet."
• REST API force-cancel (POST .../force-cancel) for both runs: same 409.
• Web UI: PUT https://github.com/TRGamer-tech/Rezeptli/suites/109024272205/cancel returns HTTP 422, body {"message":"Failed to cancel workflow."} (x-github-request-id 75DA:1CFCFD:360F84:8B5EED:6ADE5B77, 2026-10-25 19:41:47 GMT, edge region switzerlandnorth).

What works

• Another workflow ("Android CI") dispatched on the same commit at 19:03 UTC ran normally and finished green (run id 40224206818). So runners, billing and the repository in general are fine.
• githubstatus.com shows no Actions incident.
• Run Enable single file upload having size larger than 100mb at once #68 of the same workflow (schedule, 2026-10-12) succeeded. Since then no scheduled run appears, which may be related.

Workflow details that might matter

• concurrency group "rezeptindex", cancel-in-progress: false
• job uses environment "github-pages" (actions/configure-pages@v5, upload-pages-artifact@v3, deploy-pages@v4)
• permissions include pages: write

Request
Please clear or force-cancel runs #69 and #70 (suite 109024272205 and the suite of #70) so the concurrency group is released, and check why dispatches of this workflow are not being scheduled onto a runner.

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

[dosymep]

I think I may have found the cause of this issue. It could be related to outdated action versions that are no longer listed in the GitHub Actions Marketplace.

For example, check if your workflows use actions/checkout@v4. The Marketplace currently lists version 5 and newer.

My suspicion is that referencing an older action version might cause workflows to get stuck in the Queued state.

I recommend checking all the actions used in your workflows and updating them to their latest stable versions to see if that resolves the issue.

[TRGamer-tech]

Thanks for the suggestion. I checked this against my runs, and I don’t think outdated actions are the cause here.

The same workflow files, with the same actions/checkout@v4 and other v4 actions, ran fine before and after the stuck runs. Run #72 completed successfully, as did all of my CI runs the same day. The two stuck runs (#69 and #70) were started from the same workflow at the same time as the successful ones.

What the stuck runs have in common is that they never got a single job (the jobs list is empty) and could not be cancelled: the cancel call returns 409 Cannot cancel a workflow run that has not been queued yet. That looks like a problem on GitHub’s side, not like a version issue in the workflow.

I am still updating the actions to the latest major versions, since the logs warn that the v4 ones run on Node 20 and are being forced to Node 24. But I expect that to fix the warning, not the stuck runs. I’ll post an update if the stuck runs behave differently afterwards.

[TRGamer-tech]

Update: I updated the actions to their latest major versions (checkout, setup-java, setup-node, upload-artifact, setup-gradle → v5; upload-pages-artifact → v4). Everything runs fine with them, and the Node 20 deprecation warning now only mentions two actions I haven’t bumped.

As expected, this did not change anything about the stuck runs. #69 and #70 are still sitting in “queued” with an empty jobs list, and I still can’t cancel them (409 Cannot cancel a workflow run that has not been queued yet). New runs of the same workflow start and finish normally, both before and after the update. So I’m fairly sure the old action versions were not the cause.

Has anyone seen runs like this clear up on their own, or found a way to remove them?

[dosymep]

I ran into the same issue. After updating the GitHub Actions to their latest versions, everything started working fine for new runs. However, the old runs are still stuck in the queue, and I haven't found a way to cancel or remove them.