Workflow queued with no jobs; cancel and force-cancel both return HTTP 409

[robcam55]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

A manually dispatched GitHub Actions workflow is stuck in an inconsistent state:

• The run API and web UI report queued, with no conclusion.
• The jobs and artifacts APIs return no entries; no pending deployment approvals
  are present. The run timestamps have not advanced for several hours.
• A single normal cancellation and a single force-cancellation each returned
  HTTP 409 with: "Cannot cancel a workflow run that has not been queued yet."
• No replacement run or rerun has been dispatched after these responses.

GitHub's troubleshooting guidance describes this symptom and recommends Support:
https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#canceling-workflows

The authenticated Support portal says technical support is not included for this
account and offers no Actions technical-support category. There is no billing
warning on the run page. We have not changed billing or purchased a plan.

Is there an official private route for reporting this apparent Actions control-
plane inconsistency, or can GitHub staff advise how to clear the stuck empty run?
We can supply identifiers through an eligible private channel if needed. Please
do not start replacement runs, enable workflows or change billing.

We are retaining the exact API receipts privately. This post intentionally omits
repository and run identifiers and is not a request to bypass support eligibility.

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

[NexzaDev]

Hi @robcam55,

Your description matches a case that GitHub's troubleshooting docs call out explicitly, so I'll summarise what the docs say and what you can still do while waiting.

1. This is a recognised "stuck run" state

The "Canceling Workflows" section of the troubleshooting page says that if a run stays queued or in progress after cancellation attempts, it may be stuck in an abnormal state. The signs listed include no jobs being created, "Failed to cancel workflow" in the UI, or the cancel / force-cancel endpoints returning HTTP 500 or 409. That is what you're seeing. The same section says self-service cancellation, including force-cancel, may not clear such a run, and that GitHub Support needs to clear it. So your reading of the docs is correct, and the fact that both calls return 409 is consistent with that state rather than a mistake in how you called the API.

2. Check whether it's blocking other runs

The docs note that if your repository uses concurrency, a stuck run can keep blocking later runs in the same concurrency group. If you use a concurrency: block, check whether newer runs are stuck behind it. If they are, you could temporarily change the group key (for example, include a branch name or a suffix) so new runs aren't queued behind the stuck one. I know you asked not to start replacement runs, so only do this if the blocking becomes a problem for you.

3. Rule out a platform incident

Look at https://www.githubstatus.com for an Actions incident around the time the run was created. If there was one, the run may be cleaned up once it's resolved.

4. Routes to reach GitHub

I can't speak for GitHub, and I can't confirm which Support categories are available on your plan. These are the routes I'm aware of:

• The Support portal at https://support.github.com. The docs say contacting it is the path for clearing a stuck run. If the form lets you choose a category other than technical support (for example, account or billing), choosing the one closest to an Actions access problem may still get the ticket seen, but I can't guarantee how it will be triaged.
• This discussion with the Bug label, which is already cataloged by GitHub's automation. Staff may read it, but there's no guaranteed response time.
• Documentation feedback: if you think the docs should say what free-plan users should do, you can report it on the docs page (the "Make a contribution" and feedback links), which goes to the docs team.

5. What will help whoever picks this up

Since the post omits repository and run identifiers, nobody on the GitHub side can act on it as written. If the repository is public, or once you're in a channel that allows it, include the repository name, the run ID, the check suite ID if you have it, the exact timestamps, and the request IDs from the 409 responses.

I'd avoid repeated cancel attempts, as they won't change the outcome and the docs indicate they can't clear this state.

Hope this helps, and please post back if you find a route that works, as others may hit the same issue.

[robcam55]

Thanks. I checked the suggested items. The manual-dispatch concurrency key already
includes the individual run ID and attempt, so changing a shared branch group
would not address this run's configuration. When I checked after your reply,
GitHub Status listed Actions as operational and reported no incident on October 25:
https://www.githubstatus.com/

The readback retained after your reply still shows queued, no conclusion, zero
jobs and zero artifacts. For GitHub staff who can investigate:

• Run ID: 40171059798
• Check-suite ID: 108879256143
• Created, run_started and updated: 2026-10-25T06:59:00Z; attempt 1

The repository is private. I am keeping its name, source and raw receipts out of
this public thread. The Support portal says technical support is not included for
my account and offers no Actions technical-support category. Is there a legitimate
private route for staff to receive the remaining details and clear this run?

I have not repeated cancellation, changed concurrency, launched a replacement,
enabled workflows or changed billing in response to this discussion.