GitHub Pages permanently blocked by stale in-progress deployment lock

[abdymok]

🏷️ Discussion Type

Bug

Body

My repository abdymok/40 is unable to publish new GitHub Pages deployments.

Every workflow completes the Jekyll build and artifact upload successfully, but the deployment stage fails because GitHub Pages reports an old deployment as still in progress.

The stale deployment (ID 7470420548, commit c493cc70fc7c47dcf12189d47e17ea62b18b1931) was marked failed and deleted through the Deployments API. Pages nevertheless continues to report the same in-progress lock.

Latest failed workflow: https://github.com/abdymok/40/actions/runs/41289420305

Request ID: 4740:30F34C:3CAD221:C9EFB35:6AE6F9C0

Could a GitHub Pages engineer investigate and clear the underlying service-side deployment lock?

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

[abdymok]

Summary

A GitHub Pages deployment completed successfully, but subsequent deployment requests began failing because GitHub continued to treat that already-finished deployment as still in progress.

This resembles the stale-deployment condition reported in actions/deploy-pages #22. Our case differs in one important respect: the deployment identified as blocking ours explicitly reached “Reported success!” in its own deploy log.

Environment

Repository: https://github.com/abdymok/40

GitHub-managed Pages workflow: pages build and deployment

Deploy action: actions/deploy-pages@v5

Artifact size: approximately 326 MB

Build and artifact upload succeed. Failure occurs when creating the next Pages deployment.

Sequence — 1 November 2026 (UTC)

08:09:26 — Run #1385, commit c493cc70fc7c47dcf12189d47e17ea62b18b1931, starts.

08:10:19 — GitHub creates the Pages deployment.

08:10:25 — Status: deployment_in_progress.

08:10:32 — Status: syncing_files.

08:10:43 — The deploy log says “Reported success!” and evaluates the environment URL. The deploy job succeeds.

08:17:48 — First subsequent deployment request, run #1386, fails. Request ID: DC00:38FB39:182E35:4FFF26:6AE6F5DE.

Runs #1387, #1388, #1391, and #1392 fail with the same condition.

[abdymok]

deployment has recovered and cite run #1393.

[joshua-lehmann]

We hit the same finished-deployment/stale-lock symptom on 5 November 2026 in joshua-lehmann/cores3-apps.

Every custom Actions deployment failed saying SHA 4c8653c511b71953a4c5fd97927d354abf3824fa was still in progress. The Pages deployment-status API reported it finished, while the dedicated Pages cancellation endpoint returned HTTP 400 because it was already finished. Serializing deployments, fresh runs, unique artifact names, and disabling/re-enabling Pages did not recover the custom deployment path. After the reset, the site returned 404. Example failed run, request ID 8420:3F8F95:BB290F:2661306:6AECD2E1.

A recovery that worked for us: publish the prebuilt static site to a dedicated gh-pages branch (including .nojekyll), then change Settings → Pages → Source from GitHub Actions to Deploy from a branch → gh-pages → / (root). Allow that branch in the github-pages environment if deployment protection restricts branches. Our first branch-based deployment and a subsequent automated deployment succeeded; the existing HTTPS URL is serving the current build again.

For ongoing automation we build in Actions, push only the output to gh-pages, then explicitly request POST /repos/{owner}/{repo}/pages/builds with Pages write permission, since GITHUB_TOKEN pushes do not reliably trigger branch builds by themselves. Workflow and recovery notes.

This is an observed workaround, not proof the backend lock is cleared, and branch publishing still uses GitHub's hosting backend. I’m following this thread for an upstream explanation or permanent fix.