Pages workflow stuck in "Queued" — cancel, force-cancel (409) and delete (403) all fail

[Yuki0117-S2]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Repository: https://github.com/Yuki0117-S2/Memo
Workflow: pages-build-deployment (GitHub-managed, no YAML in repo)
Run URL: https://github.com/Yuki0117-S2/Memo/actions/runs/31099140854
Run ID: 31099140854
Run number: #133
Branch: main
Stuck since: 2026-08-06 20:54 KST (UTC+9)
Plan: Free

Problem:
A pages-build-deployment run has been stuck in the "Queued" state and
cannot be cancelled or deleted by any available method. Because of this,
no Pages deployment has ever succeeded on this repository and the site
is not published at all.

What I tried:

1. UI cancel
   -> "Failed to cancel workflow."

2. REST cancel
   POST /repos/Yuki0117-S2/Memo/actions/runs/31099140854/cancel
   -> HTTP 409
   {"message": "Cannot cancel a workflow re-run that has not yet queued.",
   "documentation_url": "https://docs.github.com/rest/actions/workflow-runs#force-cancel-a-workflow-run",
   "status": "409"}

3. REST force-cancel
   POST /repos/Yuki0117-S2/Memo/actions/runs/31099140854/force-cancel
   -> HTTP 409 (identical message)

4. gh run delete 31099140854 -R Yuki0117-S2/Memo
   -> HTTP 403: Could not delete the workflow run

5. Verified Pages configuration is correct:
   Source = Deploy from a branch
   Branch = main
   Folder = / (root)
   No custom domain

6. Repository contains plain static HTML at root (index.html present).
   No build step is required.

Deploy job log (actions/deploy-pages@v5) from the last failing run:

Fetching artifact metadata for "github-pages" in this workflow run
Found 1 artifact(s)
Creating Pages deployment with payload:
{ "artifact_id": 8968049256,
"pages_build_version": "a3f4f2ac89d2655a721f0fd2ae1545cffc23b79b",
"oidc_token": "***" }
Created deployment for a3f4f2ac89d2655a721f0fd2ae1545cffc23b79b
Getting Pages deployment status...
Error: Deployment cancelled.

Note the contradiction: the UI displays the run as "Queued", while the
API responds that the run "has not yet queued". The run record appears
to be in an inconsistent state on the backend.

Since cancel, force-cancel and delete are all rejected, there is no
remaining user-side action available. Could staff clear this orphaned
run server-side so that Pages deployments can proceed again?

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

[caustik]

I'm getting "Failed to cancel workflow." on a private self-hosted runner workflow.

All subsequent workflows show as queued and also fail to cancel.

[isd-hub]

Same problem - queued and unable to delete. tried all the steps available on support forums and had two seperate AI walk me through everything to make sure it wasnt something i could fix.
when everything came up as a backend issue, the automated ticket response said it was closing the ticket because “ After reviewing your account and the nature of your request, the support resources currently available to you are..”

now im stuck with that, unable to keep working.

[ebndev]

Hi! We appreciate you reaching out to report this issue.

Yesterday, August 6th, some Actions Runner Controller (ARC) runner pods became stuck in an idle state. Affected users can delete those pods using kubectl or redeploy their Actions Runner Controller application. ARC will automatically create replacement runners.

The next releases of Actions Runner and Actions Runner Controller will include an automatic recovery mechanism, preventing the need for these manual steps in the future.

This incident has been resolved and detailed root cause analysis will be shared as soon as it is available on our incident page.

If you continue to experience issues or have additional details you’d like to share, please comment on or subscribe on this discussion.

Thank you for your patience and understanding as we addressed this issue.