GitHub Pages deployment queued for days; full rerun creates no new jobs

[stefanyoooo]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Our public GitHub Pages deployment has been stalled since November 6, 2026. What is the safe recovery or escalation path?

Repository: https://github.com/stefanyoooo/movement-challenge
Run: https://github.com/stefanyoooo/movement-challenge/actions/runs/42267974335
Commit: e8e850d6383aee5470643abc21ae4558b5487025
Site: https://stefanyoooo.github.io/movement-challenge/

All times below are UTC.

On November 6, build and report-build-status succeeded. Deploy job 128064840269 created the Pages deployment, repeatedly reported deployment_queued, then failed with "Deployment failed, try again later." An initial retry remained queued.

On November 11, the API confirmed cancellation as completed/cancelled at 17:13:16. We then selected Re-run all jobs once; it was accepted at 17:14:15 for the same commit.

The current run still reports queued, conclusion null, run_attempt 1. Latest jobs are empty. The browser shows Latest #2 but lists only failed Attempt #1. The pending_deployments endpoint returns an empty array. No approval or billing warning is shown. The public site still serves the previous version.

We have made no further retries or settings changes. A Pages deployment lock has not been confirmed; its status was unavailable through our authorized tooling.

I searched for similar discussions, including https://github.com/orgs/community/discussions/211809 and https://github.com/orgs/community/discussions/210078. Our cancellation was confirmed, but the subsequent full rerun still has no new jobs. Could GitHub staff investigate whether the run/check suite or Pages deployment state is stuck or out of sync, or advise the correct escalation route?

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

[kittimzhe]

Since Nov 6 you're four days into the same syncing_files-stall cluster that's been active this week — #212606, #212625, #212641 and #212697 all report Pages deployments stalling at or around that step. That pattern is Pages-backend-side (the step hands your artifact to the backend), not your build. What has worked across the cluster:

1. Re-run the failed deploy job (Actions → run → re-run failed jobs). Fresh attempt, new backend slot — several cases landed on attempt two or three.
2. If re-runs keep stalling, a trivial new push starts a completely fresh deployment (new run, new artifact) — this lands when re-runs don't.
3. If it's been days of attempts, the heavier reset: Settings → Pages → switch the publishing source away and back, which re-creates the deployment path end-to-end.

One distinction worth checking in your case: if the stalled run shows queued with zero jobs ever created (rather than a deploy job that started and hung at syncing_files), that's the orphaned-run variant instead — cancel will 409, nothing will progress it, and the documented cleanup is deletion at the two-week mark (Nov 20–21 for a Nov 6 run). The two look similar in the UI but have different outcomes: orphans never recover, sync-stalls usually do on retry.

[aesharhel-bot]

Thanks for sharing this detailed report. I'm researching GitHub Actions reliability and deployment monitoring.

I'm curious: how did you identify that the issue was happening during the Pages deployment stage rather than the build process?

Do you currently use any external monitoring tools to detect stalled deployments, or do you rely on GitHub Actions manually?

I'd really appreciate hearing about your experience.