GitHub Actions · GitHub Pages · Checked November 5, 2026

GitHub Pages "Deployment request failed due to in progress deployment": a deploy stuck in updating_pages, "Timeout reached, aborting!" and cancelling by commit SHA

GitHub Pages runs one deployment at a time for a site. actions/deploy-pages creates a Pages deployment and then polls its status until it reaches succeed. If that takes longer than its timeout, at most 10 minutes, the step fails and asks GitHub to cancel the deployment. When the deployment stays in progress on GitHub's side anyway, every later deploy is refused until it ends. Public reports of this cluster around GitHub incidents that included Pages: October 30, 2026 (14:31 to 15:02 and 17:50 to 19:23 UTC) and November 4 (16:05 to 17:01 UTC), on GitHub Status.

What it looks like

First, a deploy whose build and upload passed waits in one status and gives up. From a run on November 5 (community discussion #212111):

Current status: updating_pages
...
Error: Timeout reached, aborting!
Canceling Pages deployment...

Then the next deploy fails at once. deploy-pages prints "Failed to create deployment (status: 400) with build version ..." and the reason from GitHub (#209206):

Deployment request failed for 18c640c4fad2919b76dbe05354f82cf895184fe4 due to in progress deployment. Please cancel d4f30a1150f384f9d508f937131f31d930442917 first or wait for it to complete.

Often a re-run also stays in Queued, and cancelling it answers "Cannot cancel a workflow run that is not in progress" or, for force-cancel, HTTP 409. That part is the Actions run, not Pages: see when a run will not stop, and force-cancel.

Cancelling the deployment that blocks

The SHA after "Please cancel" names the deployment that holds the site. The Pages REST API accepts that commit SHA in place of a deployment ID (GitHub's REST documentation for Pages). With GitHub CLI and write access to the repository:

gh api repos/OWNER/REPO/pages/deployments/SHA
gh api -X POST repos/OWNER/REPO/pages/deployments/SHA/cancel

• The first request shows the status. deployment_in_progress, syncing_files, finished_file_sync, updating_pages and purging_cdn are still in progress; cancel it with the second request, which answers 204, then re-run the failed deploy job.
• If the status already says succeed and the cancel request answers HTTP 400 that the deployment is finished, the lock is held on GitHub's side, and the people who reported it found nothing on their side that cleared it (#211780, and a reply in #209206 on November 1). In the reports from September 30 and November 4, deploys succeeded again on their own within about a day. If it lasts, contact GitHub Support with the request ID from the failed step.
• Marking the github-pages environment's deployment inactive through the Deployments API does not help: that is the environment's record of the deploy, not the Pages deployment (#212093).
• A longer timeout does not help either. deploy-pages caps it at 600000 ms, the default, and prints a warning for larger values.

Not causing it yourself

• Keep cancel-in-progress: false on the Pages concurrency group, as in GitHub's starter workflows (group: "pages"). With true, a newer push or a pull request run in the same group cancels a run in the middle of its deploy, and the next deploy can find the old deployment still in progress (evo-platformer #22; caliptra-rtl #1503, where the summary said "Canceling since a higher priority waiting request for pages exists"). With false, GitHub still keeps only the newest pending run in the group.
• Keep pull request builds out of the pages group, or skip their deploy job, so they cannot cancel a deploy from your default branch.
• With "Deploy from a branch", the run is the generated "pages build and deployment" workflow and there is no file to change. Re-run it after the blocking deployment ends, or move to a custom workflow if you need the concurrency setting.

Telling it apart

• "Failed to create deployment (status: 404) ... Ensure GitHub Pages has been enabled": Pages is not set to the GitHub Actions source yet ("Get Pages site failed").
• "Branch ... is not allowed to deploy to github-pages due to environment protection rules": a rule on the environment, not a stuck deployment (environment protection rules and github-pages).
• status 403 with "Ensure GITHUB_TOKEN has permission "pages: write"": the deploy job needs pages: write and id-token: write.

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so a deploy job that timed out and the queued run behind it are side by side, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

GitHub, GitHub Actions and GitHub Pages are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: When a run will not stop, and force-cancel · "Get Pages site failed" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語