GitHub Pages deployment stuck in Queued status for over 14 hours — no jobs appearing

[ewohbenjaminf]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Labels: Bug, Actions, Workflow Deployment

Discussion Details

Hello GitHub Actions Community,

I am experiencing a problem with GitHub Pages deployment in my repository.

Repository: https://github.com/ewohbenjaminf/wdd231

The "pages build and deployment" workflow has remained in Queued status for more than 14 hours.

Deployment details:

• Repository: ewohbenjaminf/wdd231
• Workflow: pages build and deployment
• Branch: main
• Affected workflow runs: iOS bug report: strange backstack behavior when navigating to a file #4 and Feature request: support jumping to lines in files #5
• Latest workflow run ID: 43098350754
• Latest commit: e051eb032a8207f5c0ab79ef8eeac721fcf100ec
• Pages source: Deploy from a branch
• Branch/folder: main / (root)

What I have observed:

1. Both recent deployment runs remain queued.
2. No jobs appear under All jobs.
3. The only available action is Delete workflow run.
4. My Pages configuration appears correct.
5. Previous deployments completed successfully.

Could someone help determine why these deployment jobs are not being assigned to a runner?

Is this a GitHub Actions infrastructure issue, and how can I safely restore deployment without affecting my repository or committed files?

Thank you for your assistance.

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

[ewohbenjaminf]

The rerun is still queued after five minutes and that the previous attempt showed a startup failure.

[atokim4]

Looks like your "Trigger GitHub Pages redeployment" commit (660e0e7, Nov 12 20:55 UTC) did the job. The public run list shows a new pages build and deployment run, 43305269563, that finished with success at 20:57 UTC, and the github-pages deployment for it reports success with https://ewohbenjaminf.github.io/wdd231/ as the URL. So your site is serving that commit now.

The two that still say Queued (43095834530 for b172b55 and 43098350754 for e051eb0) are leftovers from the Nov 11 incident. jobs?filter=all returns 0 jobs for both, so nothing ever started and nothing is holding the queue. Your newer run went through fine with those two still sitting there. They won't start by themselves, and rerunning them just gives the startup failure you saw. The content from those commits is already in the newer deploy because it built from the tip of main.

To clean them up you can delete them from the run page, or:

gh run delete 43098350754 -R ewohbenjaminf/wdd231
gh run delete 43095834530 -R ewohbenjaminf/wdd231

If delete gives you a 409/403 like a lot of people are getting this week, just leave them. They're cosmetic and won't block later deploys.

[kaluarachchiteshan]

Hi,

A "pages build and deployment" run stuck in Queued with no jobs is usually a stuck run record on GitHub's side. Your run ID (43098350754) is very close to run IDs in other reports of the same symptom from the same period (for example discussions #212761 and the Queued/"Failed to cancel" reports), which points to a platform-side issue rather than something in your repository. Here is how to recover without touching your files.

1. Check for a GitHub incident

Look at https://www.githubstatus.com for Actions or Pages incidents around the time of your pushes. Runs queued during an incident can stay stuck after it is resolved.

2. Try to cancel the stuck runs

You said only "Delete workflow run" is available. Try the API, which has a force-cancel endpoint for runs that don't respond to a normal cancel:

gh api -X POST repos/ewohbenjaminf/wdd231/actions/runs/43098350754/force-cancel

Do the same for the other stuck run (replace the ID). Your token needs the repo scope. If the API refuses, deleting the stuck runs is safe: it removes only the run record, not your code or your site.

3. Trigger a new Pages build without changing your files

Pages "Deploy from a branch" builds run automatically on push. To start a new one with no content change, either:

• Push an empty commit (it changes no files, only adds a commit):

git commit --allow-empty -m "Trigger Pages build"
git push origin main

• Or temporarily change the Pages source and change it back: Settings → Pages → Source → switch to another branch or "None", save, then switch back to main / (root). This often kicks off a fresh deployment.

If a stuck run is still in the queue, delete it first so it can't block the new one. Pages deployments use a concurrency group, so a stuck run can hold up the queue behind it.

4. Check settings that can block a Pages build

• Settings → Actions → General: Actions must be enabled, and policies must not block GitHub-owned actions (Pages builds use them).
• Settings → Pages: confirm the source and branch are correct, and that there are no errors shown on that page.
• Billing: for a private repository, check minutes and spending limits. Public repositories are not affected.

5. If it still doesn't start

Contact GitHub Support (https://support.github.com/contact) with the repository name, the run IDs, the commit SHA (e051eb0), the times they were queued, and the steps above. They can clear stuck runs on the backend.

Your files and committed history are not at risk from any of these steps. The worst case is a delayed site update.