GitHub Pages deployment stuck in Queued state after timeout

[gal2025]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Hello GitHub Community,

I'm experiencing a GitHub Pages deployment issue with the following repository:

Repository: https://github.com/gal2025/projeto_clinica

Website: https://joaogalrica.pt/projeto_clinica/

Workflow run: https://github.com/gal2025/projeto_clinica/actions/runs/42090443498

Problem:

My GitHub Pages site is configured to deploy from the main branch, using the root directory.

The build and report-build-status jobs completed successfully, but the deployment job failed after approximately 10 minutes with:

Error: Timeout reached, aborting!

The deployment logs repeatedly showed:

Current status: updating_pages

I tried rerunning the workflow, but the latest attempt remains stuck in the Queued state.

When I attempted to cancel it, GitHub returned:

Cannot cancel a workflow run that is not in progress.

The repository contains updated HTML and CSS, but the live website continues to serve an older version.

What I've checked:

• GitHub Pages and Actions are reported as operational.
• The main branch is configured as the deployment source.
• The github-pages environment allows deployment from main.
• No required reviewers or wait timers are enabled.

Has anyone experienced this issue? Is there a way to clear a stuck GitHub Pages deployment or trigger a fresh deployment safely?

Thank you for your help!

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

[devpryan7792]

What you're describing matches the recent Actions/Pages incidents: GitHub logged a major Incident with Actions and Pages on Nov 4 (16:05–17:01 UTC), further Actions incidents on Nov 4–5, and degraded performance for Actions and Pages from Nov 5 23:36 to Nov 6 00:20 UTC (history: https://www.githubstatus.com/history). A deployment caught during those windows can stay in updating_pages until the deploy job aborts with Timeout reached, aborting! — exactly what your run 42090443498 shows — and retries then fail because the previous deployment still counts as in progress.

The fix is to cancel the stuck Pages deployment (not the workflow run) and then deploy again. The Pages deployments API accepts the commit SHA of the deployment:

gh api repos/gal2025/projeto_clinica/pages/deployments/<COMMIT_SHA>
gh api --method POST repos/gal2025/projeto_clinica/pages/deployments/<COMMIT_SHA>/cancel

<COMMIT_SHA> is the head commit of run 42090443498. The cancel call returns 204 when done — reference: Cancel a GitHub Pages deployment.

After that, re-run the deploy job; it should complete normally. Cancelling a stuck deployment doesn't touch your published site or your custom domain — it only clears the in-progress deployment record that is blocking new ones. If a fresh run still fails the same way, contact GitHub Support with the run ID.