GitHub Actions / Pages workflows stuck in Queued state and cannot be cancelled

[CandyCheng-git]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Repository:
https://github.com/CandyCheng-git/Candycheng-git.github.io

Problem:
Multiple GitHub Actions / GitHub Pages workflow runs are stuck in Queued state and cannot be cancelled.

Affected runs:

• Deploy to GitHub Pages Proposal feature : Multi-repository discussions #41 — manually run — branch main — queued
• Deploy to GitHub Pages Will Discussions will be available for private repositories ? #40 — manually run — branch main — queued
• pages-build-deployment Why no Lollipop ? #76 — branch main — queued

Error:
When attempting to cancel, GitHub shows: “Failed to cancel workflow.”

Expected result:
The queued runs should start, finish, or be cancellable.

Request:
Please investigate or clear the stuck GitHub Actions / GitHub Pages deployment queue for this repository.

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

[Farshidbagheri]

This looks more like a stuck Actions / Pages queue issue than something that can be fixed only from the workflow YAML.

A few things I would try before escalating it:

1. Try cancelling from the REST API instead of the UI

Sometimes the UI shows “Failed to cancel workflow”, but the API gives a clearer response.

You can try normal cancellation first:

gh api \
  -X POST \
  repos/CandyCheng-git/Candycheng-git.github.io/actions/runs/RUN_ID/cancel

If the run is really stuck, try force-cancel:

gh api \
  -X POST \
  repos/CandyCheng-git/Candycheng-git.github.io/actions/runs/RUN_ID/force-cancel

Replace RUN_ID with the workflow run id from the run URL.

2. Check whether this is a runner availability issue

If the workflow uses GitHub-hosted runners, it may be a temporary GitHub-side queue problem.
If it uses self-hosted runners or ARC, check whether the runner scale set actually has online/available runners.

For ARC/self-hosted runners, I would check:

• repository/org runner status
• whether runners are online
• whether jobs are matching the correct labels
• whether ARC pods are healthy
• whether the controller can create new runner pods

3. Check concurrency settings

If the workflow has a concurrency: block, it may be holding or replacing queued runs in a way that is confusing. I would inspect the workflow YAML for something like:

concurrency:
  group: ...
  cancel-in-progress: ...

If multiple Pages deployments share the same concurrency group, one stuck/pending run may block later deployments.

4. Temporarily disable the workflow

If the repository keeps creating new queued runs, temporarily disable the workflow from:

Repository -> Actions -> workflow -> Disable workflow

Then try cancelling or force-cancelling the existing runs.

5. Check GitHub Status and Support

If normal cancel and force-cancel both fail, and the runs stay queued for a long time, this probably needs GitHub staff intervention. Community members cannot clear GitHub’s backend deployment queue for a repository.

In that case, I would open a GitHub Support ticket and include:

• repository URL
• affected workflow run URLs
• run IDs
• whether normal cancel fails
• whether force-cancel via API fails
• whether this is GitHub-hosted runner, self-hosted runner, or ARC
• workflow YAML file involved
• timestamp/timezone when the queue got stuck

For a GitHub Pages deployment queue specifically, I would also check the Pages settings and make sure the configured source/build workflow is still valid and not repeatedly triggering conflicting deployments.

So the short version is:

• Try API cancel.
• Try API force-cancel.
• Check runner/ARC availability if applicable.
• Check concurrency settings.
• Disable the workflow temporarily if it keeps queuing.
• If force-cancel also fails, escalate to GitHub Support because only GitHub can clear a backend-stuck queue.

[CandyCheng-git]

Thanks — I tried the REST API force-cancel approach.

I authenticated with GitHub CLI successfully, listed the queued runs, and attempted force-cancel on all three run IDs:

• 26326705747
• 26326609020
• 26326360756

All returned HTTP 500:

"message": "Failed to cancel workflow run"

So this looks like a GitHub backend-side issue now. I’ll disable the workflow temporarily to avoid creating more queued runs and escalate this to GitHub Support with the run IDs, URLs, CLI output, and workflow YAML.

[Farshidbagheri]

Thanks for checking and sharing the result.

Since force-cancel also returns HTTP 500 for all three runs, I agree this now looks like a GitHub backend-side Actions/Pages queue issue rather than a workflow YAML or local CLI/auth problem.

Disabling the workflow temporarily sounds like the right next step to prevent new queued runs from being added while Support investigates.

For the Support ticket, I would include exactly what you listed, plus:

• the three run IDs
• the run URLs
• the exact gh api commands used
• the HTTP 500 response body
• whether normal cancel and force-cancel both fail
• the workflow YAML
• repository URL
• timestamp/timezone when the issue started

If this troubleshooting path helped confirm the root cause and gives others a useful workaround/escalation path, feel free to mark the answer so future users can find it quickly.

[CandyCheng-git]

Thanks — that makes sense.

I have now confirmed the issue through both the UI and GitHub CLI/API:

• The queued runs are:

  • 26326705747 — Deploy to GitHub Pages Proposal feature : Multi-repository discussions #41
  • 26326609020 — Deploy to GitHub Pages Will Discussions will be available for private repositories ? #40
  • 26326360756 — pages build and deployment Why no Lollipop ? #76

• UI cancellation fails with “Failed to cancel workflow”.

• GitHub CLI authentication is valid and includes repo and workflow scopes.

• REST API force-cancel was attempted for all three run IDs.

• All three force-cancel requests returned HTTP 500 with:
  "message": "Failed to cancel workflow run"

I agree this now looks like a GitHub backend-side Actions/Pages queue issue rather than a local CLI, authentication, or workflow YAML issue.

I’ll disable the workflow temporarily, collect the run URLs, API commands, HTTP 500 responses, workflow YAML, repository URL, and timestamp/timezone, then escalate this to GitHub Support.

Thanks again — I’ll mark this as the answer since it helped confirm the root cause and gives a clear escalation path.

[Farshidbagheri]

Thanks again for the detailed follow-up. I’m glad the troubleshooting steps helped confirm that this is likely a GitHub backend-side issue.

Small request: if my original answer was the one that helped identify the escalation path, could you please mark that answer instead? That would make the troubleshooting steps easier for future users to find directly.

Of course, no problem either way — I just wanted to keep the accepted answer pointing to the main diagnostic path that helped resolve the discussion.

[shanelord01]

I'm having this same issue. Last successful run was 2 hours ago.

[fabri2000779]

same issue here, i know is weekend but feels weird that they dont even update their status page :(

[CandyCheng-git]

I've been struggling with this issue for three days now... I hope the GitHub team can respond to me soon.

[CandyCheng-git]

https://support.github.com/ticket/personal/0/4410403

Hi all, I got the reply!!

Screenshot_20260528_083629_Chrome.jpg

[sanikolaev]

What's there? It's not publicly available.

[mangaljptech]

@CandyCheng-git can you add the reply here? the link is not working

[cpualei]

It's unclear to me what that response means. Does it mean that although the status is in "queue", technically it was processed and no longer in queue? Thanks! @CandyCheng-git

[sanikolaev]

I'm having the same issue since yesterday in https://github.com/manticoresoftware/manticoresearch/actions/runs/26410422028

[e1101621]

I am experiencing the same GitHub Actions/Pages backend queue issue.

Repository:
https://github.com/HKUSTGZ-ML4Health-Lab/ATLAS

Stuck workflow run:
https://github.com/HKUSTGZ-ML4Health-Lab/ATLAS/actions/runs/31100635210

API status:
queued

Web cancellation:
Failed to cancel workflow.

Force-cancel API:
HTTP 409 — Cannot cancel a workflow re-run that has not yet queued.

Delete API:
HTTP 403 — Could not delete the workflow run.

The associated Pages deployment was successfully cancelled through the
Pages API with HTTP 204, but the dynamic workflow run remains stuck.

A custom Pages workflow uploads its artifact and creates a deployment,
but deployment remains in deployment_queued until timeout.

The API simultaneously reports that the workflow is queued while the
cancellation endpoint reports that it has not yet queued.

Could GitHub staff please investigate and clear the orphaned backend
workflow/deployment state?

[dorel14]

Hello same for me until 30mn in my repo

[Jtuckett-ss]

Still an issue on two of my repos

[samdsw]

Seeing this as well. Merged a PR that had passed all tests but between creating the PR and the merge, Github went down so now this has been stuck in Queued since yesterday.

[fgnoah]

See this issue in a lot of our repos since the outage yesterday. Can't cancel even from gh cli.