GitHub Pages deployment stuck at syncing_files with one clean artifact

[Sukunpro]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Hello GitHub Community,

My GitHub Pages site is still serving r1242. The r1243 release is on main, but Pages deployment repeatedly stalls at syncing_files and is canceled after the official action's 10-minute timeout.

Repository: https://github.com/Sukunpro/sukun
Live site: https://sukunpro.github.io/sukun/nero.html
Live version marker: https://sukunpro.github.io/sukun/version.txt

The clearest reproduction is a new workflow run with exactly one github-pages artifact:

• Run: https://github.com/Sukunpro/sukun/actions/runs/42781747246
• Deploy job: https://github.com/Sukunpro/sukun/actions/runs/42781747246/job/129713531024
• Commit: 35eb20e7752e879d93dfd0e5f7be622bd2979c70
• Artifact ID: 13746645989, size 460,989,521 bytes
• On 2026-11-10, the deployment entered syncing_files at 08:21:11 UTC, remained there until 08:30:43 UTC, then timed out and was canceled at 08:31:20 UTC.

Build and artifact upload succeeded. The commit only retriggered publication: it changed zero files and has the same Git tree as the tested r1243 release, 9887395a3d92bdc33971a12cfa10325ff47419cc. The release passed all 15 test workflows, including 94/94 source and native-browser acceptance checks:
https://github.com/Sukunpro/sukun/actions/runs/42776161225

For comparison, the previous r1242 deployment succeeded on 2026-11-09 with the same actions/deploy-pages version and a nearly identical artifact size (460,913,361 bytes):
https://github.com/Sukunpro/sukun/actions/runs/42656271402

Earlier attempts for r1243 are recorded here:
https://github.com/Sukunpro/sukun/actions/runs/42776160518
The first attempt stalled at syncing_files. A deploy-only retry returned blank status values and timed out. Rebuilding inside that same run then produced two artifacts with the same name, causing a separate duplicate-artifact error. The clean run linked above eliminated that duplication but reproduced the original syncing_files timeout.

We have not changed the Pages settings, publishing workflow, or permissions. The repository's files total about 536 MiB and contain no symlinks. GitHub Status showed no active incident when checked after the failure.

Could GitHub staff investigate whether this repository's Pages deployment state or file synchronization is stuck, and advise how to restore deployment without deleting the working site or changing its settings?

No credentials or private user records are included in this report.

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

[atokim4]

Looks like it went through now. Run 42800843692 ("pages build and deployment", commit 81b0298, the r1244 merge) deployed at 10:40 UTC, the deploy job took about 30 seconds, and https://sukunpro.github.io/sukun/version.txt returns r1244 for me right now.

So I don't think anything in the repo is stuck. Same artifact size, same action, and this time syncing_files finished in seconds. That points at a temporary problem on the Pages side this morning; a few other threads here had the same syncing_files timeouts on Nov 9-10. If it happens again I'd wait a bit and push an empty commit before changing the workflow.

Longer term, 460 MB is almost half of the 1 GB limit for a published Pages site, and bigger artifacts take longer to sync. If part of that is test fixtures or files the site never serves, leaving them out of the upload should make deploys quicker and less fragile.

[kittimzhe]

Quick live-check first: your six most recent runs (Nov 11 10:44 UTC) all completed successfully — so runs execute; the failure you're describing is specifically the syncing_files step inside actions/deploy-pages timing out at the action's 10-minute limit. That step hands the artifact to the Pages backend, and a stall there is backend-side, not in your build.

You're also not alone in this window — #212625 and #212641 report the same syncing_files stall signature right now, which usually means a transient Pages-backend slowdown rather than anything in the repo. What's worked in this family:

1. Re-run just the failed deploy job (Actions → the failed run → re-run failed jobs). A fresh attempt gets a new backend slot; several same-signature cases landed on the second or third attempt.
2. If every attempt stalls at the same step for hours, a trivial new push starts a fresh deployment (new run, new artifact, new sync) — often lands when re-runs don't.
3. The heavier fallback if it persists for days: temporarily switching the publishing source (Settings → Pages) away and back re-creates the deployment path end-to-end.

Your live site marker check (r1242 vs r1243) is exactly the right verification; if the stall persists across a day of attempts, cross-linking your thread with the two above gives the pattern visibility.