GitHub Actions runs stuck in queued state with no runner. Cancel and force-cancel fail

[ProposeALL]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

I’m experiencing what appears to be a GitHub Actions scheduler/control-plane issue on a private repository.

The workflow uses ubuntu-latest and was working normally earlier the same day. Subsequent workflow runs began remaining indefinitely in queued without ever receiving a runner or creating an executable job.

GitHub’s Actions UI and REST API report the affected runs as queued, but the jobs endpoint returns no jobs and no workflow steps execute. There are also currently zero workflows actually running.

Attempting to cancel one of the queued runs through the GitHub web UI returns:

Failed to cancel workflow.

I then tried the documented force-cancel endpoint with GitHub CLI:

gh api --method POST repos///actions/runs//force-cancel

GitHub returns:

Cannot cancel a workflow re-run that has not yet queued. (HTTP 409)

That appears inconsistent with both the UI and REST API, which report the same run as queued.

I have already ruled out the obvious repository-side causes:

• The same workflow and ubuntu-latest runner configuration completed successfully earlier the same day.
• Actions usage is well below the included monthly allowance, with no billable overage.
• There are zero workflows currently in progress, so runner concurrency does not appear to be exhausted.
• Repository Actions permissions are enabled normally.
• Disabling Actions for the repository, saving, waiting, and re-enabling Actions did not clear the affected queued runs.
• Closing and reopening the pull request did not produce a usable new CI execution.
• Normal cancellation through the UI fails.
• Force-cancel returns the contradictory HTTP 409 response above.
• The exact feature-branch code passes the full local validation suite successfully: 223 tests passed, 0 failed.

The failure therefore occurs before repository code or tests begin executing.

Expected behavior is that a queued workflow receives an available GitHub-hosted runner and begins execution, or transitions to canceled when cancellation is requested.

Actual behavior is that the workflow remains indefinitely queued, receives no runner, exposes no executable jobs, and cannot be canceled because GitHub simultaneously appears to consider it both queued and “not yet queued.”

This looks like an orphaned or inconsistent workflow-run state in the GitHub Actions scheduler/control plane.

Has anyone else encountered this recently, or is there a recommended way to clear these stuck workflow records without modifying or pushing new repository code?

[Zorsh1458]

There is an incident with GitHub Actions happening right now: https://www.githubstatus.com/incidents/y1t7p9fzrlj2

[Zorsh1458]

UPD: They seem to solve the problem

[ProposeALL]

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

[ArlanzaCapital]

I'm experiencing the same issue following the November 11, 2026 GitHub Actions incident.

A workflow run in a private repository remains in queued with zero jobs created. Its status has not changed since November 11 at 20:23:39 UTC.

Clicking Cancel workflow repeatedly returns "Failed to cancel workflow."

GitHub Status now reports the incident as resolved, but the individual run is still stuck.

Is there a supported recovery procedure for these orphaned workflow runs without modifying repository code or deleting unrelated evidence?

[maglothinm]

I am reporting another reproducible instance of the queued/not-yet-queued
contradiction, on behalf of the owner of public repository
maglothinm/MyETF-Intelligence (repository ID 1349678672).

Two obsolete runs remain queued with conclusion: null, zero jobs and zero
artifacts:

• https://github.com/maglothinm/MyETF-Intelligence/actions/runs/33219808359
• https://github.com/maglothinm/MyETF-Intelligence/actions/runs/33221027676

Both bind to workflow ID 344663675, path
.github/workflows/legislative_trade_tracker.yml, historical commit
b9cf0f3e3863de69d92ae01f35f1c154a082f56a. The workflow metadata now reports
state: deleted. Removing that obsolete workflow did not terminalize its runs.

At 2026-08-30 13:33:44-45 UTC, authenticated repository-admin requests to both
POST /repos/maglothinm/MyETF-Intelligence/actions/runs/{run_id}/cancel and
POST /repos/maglothinm/MyETF-Intelligence/actions/runs/{run_id}/force-cancel
returned HTTP 409, with the exact message:

Cannot cancel a workflow run that has not been queued yet.

Immediately re-reading each run still returned queued. GitHub request IDs:

Run	Endpoint	X-GitHub-Request-Id
33219808359	cancel	D8C1:160B1:C57BC63:28DE694D:6A943138
33219808359	force-cancel	D8C1:160B1:C57BD68:28DE6C88:6A943139
33221027676	cancel	D8C1:160B1:C57C0D4:28DE780B:6A943139
33221027676	force-cancel	D8C1:160B1:C57C1BE:28DE7B4B:6A943139

Other recent workflows in this repository complete successfully. This is not a
claim that all Actions are down. These particular stale runs block our controlled
production release: if old workflow code starts later, it can upload stale
production-state artifacts. We will not assume a deleted workflow or an empty jobs
list makes already queued runs harmless.

Could GitHub staff terminally cancel these exact two runs, or provide
authoritative confirmation that neither can execute or upload artifacts? If a
supported customer-side procedure exists, please explain whether it permanently
invalidates these already queued runs, including after Actions is re-enabled.

Please preserve the repository, all production artifacts and unrelated runs. We
are not requesting a state reset, artifact deletion, or execution/rerun of the old
workflow. A terminal cancellation or documented scheduler-level containment is
the outcome needed. Thank you.

[maglothinm]

Owner-authenticated follow-up, 2026-09-01 UTC:

I reauthenticated maglothinm through Git Credential Manager and retried the supported repository-admin endpoints against exactly the two affected runs.

• Run 33219808359: normal cancel HTTP 409; force-cancel HTTP 409; delete HTTP 403 (Could not delete the workflow run). It remains queued, attempt 1, zero jobs/artifacts, unchanged since 2026-08-28T23:15:32Z.
• Run 33221027676: normal cancel HTTP 409; force-cancel HTTP 409; delete HTTP 403 (Could not delete the workflow run). It remains queued, attempt 1, zero jobs/artifacts, unchanged since 2026-08-28T23:37:08Z.

The current credential can push to the repository; this is not an authentication or repository-permission failure. Other Actions runs complete normally. GitHub Status is operational.

Please terminally cancel/delete these exact backend-stuck records, or provide written scheduler-level confirmation that they can never materialize jobs, upload artifacts, or invoke secrets. We are preserving the repository and all unrelated runs/artifacts. We are not asking to rerun either workflow or reset production state.

[pavelelvelru-ui]

We are seeing the same queued/not-yet-queued inconsistency on September 13, 2026.
A GitHub-hosted Actions CI run has remained queued with zero jobs since 08:59 UTC.
The run and check suite still report queued with null conclusion and attempt 1.

Normal cancel returns HTTP 409: Cannot cancel a workflow run that has not been queued yet.
One normal rerun returns HTTP 403: This workflow is already running.

Actions and the workflow are enabled, no other runs are in progress, no deployment
approval is pending, and the visible billing/usage checks show no blocking limit.
No force-cancel or workflow deletion has been attempted.

GitHub incident https://www.githubstatus.com/incidents/0rn90wk115q9 was marked
resolved at 10:44 UTC, but this specific run remains stuck. We cannot establish
whether the incident caused it.

Is there a supported recovery procedure for zero-job runs in this inconsistent
state, or a way to send the run URL and request IDs privately to GitHub staff for
inspection? We can provide those details privately. We want to preserve the
commit and run all normal required checks, with no protection bypass.

[Cheekyfellastef]

Owner-account report for public repository Cheekyfellastef/stephan-os, 26 October 2026. We have five records with the same inconsistent lifecycle:

• 37655523112, 37655523120, 37655516122, 37655516124: created 7 October, still queued, zero jobs/check runs. Normal cancellation returns HTTP 409 “not been queued yet”; force-cancel tested on 37655523112 also returns HTTP 409. Approved deletion of each returns HTTP 403 “Could not delete the workflow run.”
• 39784345743: created 22 October, aggregate in_progress, although both jobs are terminal (mirror119843525305 success, proof119843531673 skipped). Normal and approved force-cancel return409 “not in progress”; approved deletion returns HTTP 403.

Fresh cache-revalidated reads and corresponding check suites agree with these pending aggregate states. The account has repository admin/maintain/push access; the same CLI successfully cancelled 22 obsolete waiting attempts and removed 3 other approved stale records, independently verified HTTP 404. Recent source checks run normally.

Support case 4909239 was submitted and closed because the current account support entitlement is self-service. The documented support route has therefore not cleared these records.

These five records block a required Actions drain before our command-mailbox cutover. We have exercised an authenticated DRAINING hold and are handing it back through the existing audited CANCEL path while awaiting GitHub. We retain all original commands/receipts and will not assume zero jobs means safe non-execution. No cutover is claimed.

Could GitHub staff terminalize/correct/remove these exact five records, or provide authoritative scheduler-level evidence that they cannot later execute or write? Please preserve unrelated runs, repository protections and original issue comments; do not rerun old jobs or reset the repository.

Public evidence: Cheekyfellastef/stephan-os#2315 (comment)
Audited migration fence: Cheekyfellastef/stephan-os#2315 (comment)