GitHub Actions run stuck queued; UI and API cancellation fail

[arnaldomarion]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

A manually triggered workflow run in a private repository has remained queued for several days with zero jobs and no pending deployment approvals. The Actions UI says “Failed to cancel workflow.” gh run cancel reports that the run is completed, while the force-cancel API returns HTTP 409, saying it has not been queued yet.

Is there a supported way to reconcile the run while preserving its history? I have not deleted or rerun it. Could a stuck run affect future runs in the same concurrency group?

[DaPandamonium]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

A manually triggered workflow run in a private repository has remained queued for several days with zero jobs and no pending deployment approvals. The Actions UI says “Failed to cancel workflow.” gh run cancel reports that the run is completed, while the force-cancel API returns HTTP 409, saying it has not been queued yet.

Is there a supported way to reconcile the run while preserving its history? I have not deleted or rerun it. Could a stuck run affect future runs in the same concurrency group?

This looks like a classic backend desynchronization bug on GitHub's end. It usually happens when the orchestrator registers the top-level workflow run in the database but fails to actually initialize or expand the underlying jobs, leaving the run permanently orphaned in a ghost state.
Unfortunately, there isn't a self-service way to reconcile the state while preserving its history because the system is stuck in an unresolvable loop. Your best option to clear it depends on its age: if the run is more than 14 days old, you can safely remove it using the GitHub CLI with gh run delete. If it is newer than that, you will likely need to reach out to GitHub Support so backend engineers can manually purge the corrupted record.
As for your concurrency group, it will absolutely block future runs. The scheduler views that perpetual "queued" status as an active lock, meaning any subsequent runs in the same group will sit stalled behind it indefinitely. If you need to get your deployment pipelines moving immediately, a quick workaround is to temporarily rename or add a suffix to the concurrency: group: key in your workflow YAML file to completely bypass the stuck lock.

[kittimzhe]

Your three observations are not conflicting — together they're the exact signature of the orphaned-run family documented in #209225 and #210429:

• UI "Failed to cancel" + force-cancel 409 "has not been queued yet": the run object exists, but it never entered the scheduler's queue — there is nothing for cancel to stop. The 409 text is literal.
• gh run cancel / API reporting it "completed": read endpoints and the cancel path disagree because the run has no live scheduler state to reconcile against — the record is metadata only.

Since it's a private repo I can't verify the run externally, but the self-serve path for a run stuck this way is documented and time-gated: a workflow run can be deleted once it's completed or older than two weeks. If your run has been queued "several days," wait out the two-week mark from its creation, then:

1. POST …/actions/runs/{id}/cancel (keep the 409 response — it's your evidence)
2. DELETE …/actions/runs/{id} — removes the orphaned record; pending runs on the branch proceed unaffected, since nothing was ever actually executing.

For preserving the run as evidence, export the job list and metadata first (gh api repos/{owner}/{repo}/actions/runs/{id} and …/jobs) — deletion is irreversible.

[BekirEfeoglu]

When a run is stuck in queued and even cancellation has no effect, the cause is almost always one of these, in order of likelihood:

1. GitHub-side incident or backlog. Queued-but-never-starting runs cluster during incidents (check https://www.githubstatus.com). If the status page is green, still try cancellation once more via API — the UI button sometimes hits a stale state:

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

   If that returns 500 like the UI, it's stuck server-side and only GitHub can clear it → open a ticket at https://support.github.com with the run id. They can kill it from their side; there's no self-serve force-cancel.

2. Runner never picked it up. If you use self-hosted runners: the run queues for a specific label; if no idle runner with that label exists (offline, busy on another job, or mislabeled), it waits forever. Check Settings → Actions → Runners for the runner's actual state and labels — a runner that missed a config update often still shows as Idle while not accepting work. Restarting the runner service usually unsticks the queue.

3. Spending limit / billing block (for larger hosted runners). If the repo/org has larger runners enabled and hit its spending limit, new runs queue silently. Check Settings → Billing and plans → Spending limit — a run queued behind a billing wall behaves exactly like this.

For the stuck one right now: try the API cancel once; if it errors, contact support with the run URL — that's the only remaining path, since a run that can't be cancelled from either surface is wedged on GitHub's end.