GitHub Pages deployment stuck in Queued and cannot be canceled (HTTP 409)

[PokuangZhou]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

My GitHub Pages deployment workflow is stuck in the queued state and cannot be canceled.

Repository: https://github.com/PokuangZhou/website

Affected workflow: https://github.com/PokuangZhou/website/actions/runs/42742159705

The workflow has remained queued for approximately 50 minutes without starting.

Attempts to cancel it produce inconsistent errors:

1. GitHub CLI cancellation:

   Cannot cancel a workflow run that is completed

2. REST API force-cancel:

   HTTP 409 Conflict

   Cannot cancel a workflow re-run that has not yet queued.

3. REST API status:

   status: queued, conclusion: null, run_attempt: 1

Additionally, an older GitHub Pages workflow (Run ID: 28684597525) appears to have been stuck for approximately four months.

Previous Pages deployment attempts also encountered the error:

Deployment failed, try again later.

The existing website remains accessible, but new updates are not being published.

Could GitHub staff investigate whether these workflow runs are stuck due to inconsistent backend state or a deployment queue issue?

Is there a way to clear the stuck runs and restore GitHub Pages deployments?

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

[David-Chessum]

I am having same problem.

Pages workflow #142 in David-Chessum/dc-naval-history timed out during syncing_files. Its second attempt is stuck as Queued, but cancelling returns “Cannot cancel a workflow run that is not in progress.” How can I clear or restart it?

[atokim4]

Looks like the newest commit already went out. In your repo's public run list, run 42749199683 ("pages build and deployment", commit c3a4700 from 03:23 UTC) completed with success at 03:27 UTC, about an hour after the stuck one was created. Worth a hard refresh of the site to confirm the update is live.

The queued runs don't seem to block anything either. 28684597525 has sat in queued since July, and several Pages deploys finished successfully after it, including one yesterday at 21:41 UTC. With the built-in Pages workflow, a later push starts its own run, so an orphaned run just sits in the list.

That's also why the cancel calls fail: the run never got a runner, so the API sees it as neither in progress nor finished. You could try "Delete workflow run" from the ⋯ menu on the run page, but I'm not sure that works on a queued run. If it doesn't, only GitHub support can clear it. As long as new pushes deploy, it's just clutter.

[atokim4]

@David-Chessum From your public run list, attempt 1 of run #142 (commit 7274d5c) did build fine. Only the deploy job failed after about 10 minutes, so the re-run you started is attempt 2, and it never got a runner. That one is in the same state as the run above: nothing you can cancel or restart from your side.

You don't need to clear it though. Push any new commit to the branch Pages builds from and you get a fresh "pages build and deployment" run:

git commit --allow-empty -m "redeploy pages"
git push

In the case above, Pages deploys finished fine after an orphaned queued run, so it shouldn't block the new one. If the new deploy also times out in syncing_files, check githubstatus.com for Pages incidents before changing anything in the repo. Your build step passed, so the problem was on the deploy side.

[David-Chessum]

Thank you. That worked. Best regards David From: Sunnatulla ***@***.***> Sent: Tuesday, 10 November 2026 7:22 PM To: community/community ***@***.***> Cc: David-Chessum ***@***.***>; Mention ***@***.***> Subject: Re: [community/community] GitHub Pages deployment stuck in Queued and cannot be canceled (HTTP 409) (Discussion #212587) @David-Chessum <https://github.com/David-Chessum> From your public run list, attempt 1 of run #142 (commit 7274d5c) did build fine. Only the deploy job failed after about 10 minutes, so the re-run you started is attempt 2, and it never got a runner. That one is in the same state as the run above: nothing you can cancel or restart from your side. You don't need to clear it though. Push any new commit to the branch Pages builds from and you get a fresh "pages build and deployment" run: git commit --allow-empty -m "redeploy pages" git push In the case above, Pages deploys finished fine after an orphaned queued run, so it shouldn't block the new one. If the new deploy also times out in syncing_files, check githubstatus.com for Pages incidents before changing anything in the repo. Your build step passed, so the problem was on the deploy side. — Reply to this email directly, view it on GitHub <#212587?email_source=notifications&email_token=CLO5DA7CS264QBSJOPSJIXL5YLF2HA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGEZTAMZYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19513038> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/CLO5DA3QM654CUW4GDLAUJL5YLF2HAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGY4DQNJZUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CLO5DA3PSS2VCMGHOCC4WDL5YLF2HA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGEZTAMZYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CLO5DAZRY3GCMNOFCIOKMKL5YLF2HA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGEZTAMZYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ> . Download it today! You are receiving this because you were mentioned. <https://github.com/notifications/beacon/CLO5DAZHQMNTOFFFZJXYGDL5YLF2HBFCNFSM6AAAAADE2YFJWSWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQBFG7M5JTSMVQXG33OU5WWK3TUNFXW4.gif> Message ID: ***@***.*** ***@***.***> >

[kittimzhe]

Live-checked run 42742159705: still queued, zero jobs, created_at Nov 10 02:21:12 with updated_at frozen at 02:28:55 — a day and a half with no scheduler pickup. That's the orphaned-run variant (documented across #209225, #211761, #212283): the run object exists but never entered the scheduler queue, which is exactly why your cancel attempts produce inconsistent responses — "completed" (nothing to stop) from cancel, 409 "has not been queued yet" from force-cancel (literal).

Two practical facts:

1. It isn't blocking anything — push a new commit (or re-run the workflow) and a fresh run gets its own queue entry; your site will deploy from that. Several of the recent threads in this family saw exactly that: the orphan sits there while newer deployments succeed around it.
2. Cleanup is time-gated: a run becomes DELETEable when completed or older than two weeks — for yours that's Nov 24: gh api -X DELETE repos/PokuangZhou/website/actions/runs/42742159705. Until then the queued entry is cosmetic.