Workflow run stuck queued with zero jobs and cannot be cancelled

[IronsTeo1]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Repository

https://github.com/IronsTeo1/musimatch-prod

Affected workflow run

https://github.com/IronsTeo1/musimatch-prod/actions/runs/32984162981

• Workflow: Deploy Firebase Stack (test)
• Branch: test
• Commit: 24f67ecf3389868f5713e54b7f74d35fd66aba04
• Event: workflow_dispatch
• Created: 2026-08-26T15:08:08Z
• Check suite ID: 89348995323

Problem

The run became stuck in a pre-queue state during the GitHub Actions incident on August 26, 2026. The REST API reports queued, but the run has zero jobs and has never been updated.

Cancellation failures

The normal cancellation endpoint returns HTTP 409 saying that the run is already completed.

The force-cancel endpoint returns HTTP 409 saying:

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

The web and mobile cancellation interfaces also remain stuck.

Requested help

Please purge or reconcile this ghost workflow run and confirm that it cannot unexpectedly execute later.

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

[josiahking]

I’m seeing the same ghost-queued Actions state on josiahking/evolvephp.

Push-triggered run 32984070929 on branch 2.x, SHA 6761ed4af6956024abb8e8cc5d913c908628eeea, remains queued with conclusion: null and zero jobs.

gh run cancel reports “Cannot cancel a workflow run that is completed.”

Force-cancel returns HTTP 409: “Cannot cancel a workflow run that has not been queued yet.”

A manually dispatched replacement run 32984815055 on the same SHA also became stuck in the same state.

GitHub Support closed my ticket because my current support entitlement only provides self-service resources.

The PR-triggered workflow immediately before this succeeded normally, so this appears to be an orphaned/corrupted Actions scheduler record rather than a workflow YAML or runner configuration problem.

[lefanning]

I’m seeing what appears to be the same issue on a private repository.

Affected run details:

Run ID: 32984391220
Created: 2026-08-26T15:12:46Z
Status: queued
Conclusion: null
Jobs: 0
Check runs: 0
Artifacts: 0
Cancellation through the GitHub UI fails with:

“Failed to cancel workflow.”

I also tried the documented force-cancel endpoint once after verifying the run state, and GitHub returned HTTP 409 Conflict. An immediate read-back showed no change.

A later replacement run completed successfully, so Actions itself is working again; only this original run remains stranded.

The creation time also appears to fall within the same period as the other orphaned/ghost workflow runs reported here following the August 26 Actions incident.

Ideally the stranded run needs to be terminalised as completed/cancelled without execution while preserving its audit record.

[IronsTeo1]

Thanks @josiahking and @lefanning — your reports strongly suggest this is an orphaned/corrupted Actions scheduler state related to the August 26 incident, rather than a workflow YAML or runner configuration issue.

Our original run is still queued, with zero jobs and no updates since creation. Normal cancellation and force-cancel still return the contradictory HTTP 409 responses described above.

We have not dispatched a replacement yet because we cannot confirm that the stranded run is permanently inert and will not execute later.

@lefanning could you confirm whether your original stranded run is still queued after the replacement completed, and whether it has ever started any job?

@josiahking please let us know if either of your stuck runs changes state or is cleared by GitHub.

It would be helpful if GitHub staff could reconcile these backend records and confirm that the orphaned runs cannot execute unexpectedly.

[rdevz-ph]

Same here: https://github.com/rdevz-ph/PyAMPP-Windows/actions/runs/32984652018 Funny thing is, I already pushed new updates, but this one is still stuck and I can’t even cancel it.

[IronsTeo1]

Thanks @rdevz-ph — this appears to match the same orphaned/ghost run state. Our run 32984162981 is also still queued with zero jobs and has not been updated since the August 26 Actions incident.

When you say you pushed new updates, did the newer workflow runs complete successfully while run 32984652018 remained queued, or are the newer runs also stuck? Please let us know if the original run ever creates a job or changes state. This would help establish whether these stranded records are inert or can still execute later.

[rdevz-ph]

My workaround for now is to temporarily disable the workflow, push the new update, and then re-run the workflow manually. The newer runs complete successfully after doing this, while the original run remains stuck in the queued state with zero jobs.

I’ll keep an eye on run 32984652018 and let you know if it ever creates a job or changes state.

[butikmidori]

Same issue here on a GitHub Pages repository.

Repository: butikmidori/butikmidori.github.io

Two Pages runs created during the same incident window are still stranded:

Pages #359 — Run ID 32984628486
Pages #360 — Run ID 32984671715

Both remain queued with no state update since creation. Cancelling from the GitHub UI repeatedly returns:

Failed to cancel workflow.

The previous Pages deployment #358 completed successfully.

Shortly after these Pages runs became stuck, a manually dispatched workflow (Update Product Previews #65, Run ID 32984685519) ended with startup_failure.

We have avoided creating further Pages deployments because we cannot confirm whether the stranded runs are inert or may execute later.

Please include these runs if GitHub staff is reconciling orphaned/ghost scheduler records from the August 26 incident.