GitHub Pages Workflow Stuck in Queued State with 0 Jobs – Unable to Cancel (Run #144)

[raihan0718]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Hello everyone,

I'm experiencing a persistent GitHub Pages deployment issue in my repository:

Repository: https://github.com/raihan0718/tamaverse

Problem:

The automatically generated GitHub Pages workflow (Run #144) has been stuck in the "queued" state for an extended period, with zero jobs created.

When I attempt to cancel the workflow, GitHub displays:

"Cannot cancel workflow when not in progress"

Workflow information:

• Run ID: "41071303320"
• Run number: "144"
• Commit SHA: "7fb69a59bdd7c0faa2408294aacdd2945435b501"
• Branch: "main"
• Workflow: "pages build and deployment"
• Workflow path: "dynamic/pages/pages-build-deployment"

Previous errors:

Earlier deployment attempts completed the build stage successfully but failed during deployment with HTTP 500 errors.

Troubleshooting attempted:

• Retried the failed workflow.
• Attempted to cancel the stuck run through GitHub Actions.
• Checked workflow status and job information through the GitHub API.
• Reviewed the repository deployment configuration.

The current workflow remains queued with no jobs, and I haven't found a way to cancel or recover it.

Questions:

1. Could this be caused by an inconsistent or stuck GitHub Actions workflow run?
2. Is there a safe way to clear the stuck run?
3. How can I restore normal GitHub Pages deployments without disrupting the existing repository?

Any help or suggestions would be appreciated.

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

[christoferpedrosanchezzuzunaga-eng]

Hey @raihan0718,

I've hit this exact state before. It happens when the runner allocation fails before the job actually spins up, leaving the workflow in an orphaned "queued" state with 0 jobs. Since nothing is technically running, the web UI refuses to let you cancel it normally.

The fastest way to unstick it is to force-cancel the run directly via the GitHub CLI:

gh api --method POST /repos/raihan0718/tamaverse/actions/runs/41071303320/force-cancel

If you don't have gh handy, you can flush the deployment lock from the repo settings:

1. Go to Settings > Pages and temporarily change the source from GitHub Actions to Deploy from a branch (select any branch and save).
2. Give it a minute to let GitHub drop the pending deployment.
3. Switch it back to GitHub Actions, then trigger a fresh run by pushing an empty commit (git commit --allow-empty -m "re-trigger pages" && git push origin main).

That should clear the stuck run and let your next deployment go through cleanly.

[Sagargupta16]

Your site is deploying again: runs #145, #151 and #153 succeeded after 23:40 UTC, and Pages reports the latest build (356280b) as built at 00:15 UTC. What is left is only the stuck run #144.

That run and #143 failed at the actions/deploy-pages step with Failed to create deployment (status: 500), inside a GitHub incident: githubstatus.com logged "a temporarily overloaded component triggered a burst of errors between 14:21 and 14:30 UTC", with Pages degraded until 14:49 UTC (https://stspg.io/6p81rf34z4nc). Your pushes landed at 14:21:51, 14:22:10 and 14:23:38 UTC. Run #144's deployment was created at 14:24:47 and marked failed at 14:25:03, but the run record never left "queued" with 0 jobs.

The normal cancel endpoint answers 409 for a run in that state. The force-cancel call suggested above is the documented next step for exactly this case: use it "when the workflow run is not responding to" the normal cancel (https://docs.github.com/en/rest/actions/workflow-runs#force-cancel-a-workflow-run). If it also returns 409, leave the run: it blocks nothing, as your successful deploys since then show, and Support can remove it if it bothers you. Switching the Pages source is not needed, since the site is already serving new builds.