GitHub Pages の「Deployment request failed due to in progress deployment」：updating_pages で止まるデプロイ・「Timeout reached, aborting!」・コミットの SHA で取り消す
GitHub Pages は、1つのサイトにつきデプロイを1つずつ進めます。actions/deploy-pages は Pages のデプロイを作り、その状態が succeed になるまで問い合わせ続けます。タイムアウト（最大10分）を過ぎるとステップは失敗し、GitHub にデプロイの取り消しを頼みます。それでも GitHub の側でデプロイが進行中のまま残ると、そのデプロイが終わるまで、あとのデプロイはすべて断られます。公開の報告は、Pages を含む GitHub の障害の前後に集まっています：2026年10月30日（UTC の 14:31〜15:02 と 17:50〜19:23）と11月4日（UTC の 16:05〜17:01）で、GitHub Status に載っています。
見え方
まず、ビルドとアップロードは通ったデプロイが、1つの状態のまま待って諦めます。11月5日の実行から（コミュニティのディスカッション #212111）：
Current status: updating_pages ... Error: Timeout reached, aborting! Canceling Pages deployment...
次のデプロイはすぐに失敗します。deploy-pages は「Failed to create deployment (status: 400) with build version ...」と、GitHub からの理由を出します（#209206）：
Deployment request failed for 18c640c4fad2919b76dbe05354f82cf895184fe4 due to in progress deployment. Please cancel d4f30a1150f384f9d508f937131f31d930442917 first or wait for it to complete.
実行し直した実行も Queued のまま残り、キャンセルすると「Cannot cancel a workflow run that is not in progress」、force-cancel なら HTTP 409 が返ることがよくあります。こちらは Pages ではなく Actions の実行の話です：止まらない実行と force-cancel。
止めているデプロイを取り消す
「Please cancel」のあとの SHA が、サイトをふさいでいるデプロイです。Pages の REST API は、デプロイの ID の代わりにそのコミットの SHA を受け付けます（GitHub の Pages の REST のドキュメント）。GitHub CLI で、リポジトリへの書き込み権限があれば：
gh api repos/OWNER/REPO/pages/deployments/SHA gh api -X POST repos/OWNER/REPO/pages/deployments/SHA/cancel
- 1つ目で状態を見ます。
deployment_in_progress・syncing_files・finished_file_sync・updating_pages・purging_cdnはまだ進行中なので、2つ目で取り消します。204 が返ったら、失敗したデプロイのジョブを実行し直します。 - 状態がもう
succeedで、取り消しが「終わっている」という HTTP 400 を返すなら、ロックは GitHub の側に残っていて、報告した人たちは自分の側でそれを外す方法を見つけられませんでした（#211780、#209206 の11月1日の返信）。9月30日と11月4日の報告では、1日ほどのうちにデプロイがまた自然に通るようになりました。続くなら、失敗したステップに出る Request ID を添えて GitHub Support に連絡します。 - Deployments API で
github-pagesの環境のデプロイを inactive にしても変わりません。それは環境に残るデプロイの記録で、Pages のデプロイそのものではありません（#212093）。 timeoutを長くしても変わりません。deploy-pages は既定の 600000 ms を上限にしていて、それより大きい値には警告を出します。
自分で起こさないために
- GitHub のスターターワークフロー（
group: "pages"）と同じく、Pages の concurrency のグループはcancel-in-progress: falseのままにします。trueだと、新しい push や同じグループのプルリクエストの実行が、デプロイの途中の実行をキャンセルし、次のデプロイが古いデプロイを進行中のまま見つけることがあります（evo-platformer #22・caliptra-rtl #1503。こちらではサマリーに「Canceling since a higher priority waiting request for pages exists」と出ていました）。falseでも、GitHub はグループの中で待っている実行をいちばん新しい1つだけ残します。 - プルリクエストのビルドは
pagesのグループに入れないか、デプロイのジョブを飛ばします。そうすれば、既定のブランチからのデプロイをキャンセルできません。 - 「Deploy from a branch」なら、実行は自動で作られる「pages build and deployment」のワークフローで、変えるファイルがありません。止めているデプロイが終わってから実行し直すか、concurrency の設定が要るなら自分のワークフローに移ります。
見分け方
- 「Failed to create deployment (status: 404) ... Ensure GitHub Pages has been enabled」：Pages のソースがまだ GitHub Actions になっていません（「Get Pages site failed」）。
- 「Branch ... is not allowed to deploy to github-pages due to environment protection rules」：止まったデプロイではなく、環境のルールです（環境の保護ルールと github-pages）。
- status 403 と「Ensure GITHUB_TOKEN has permission "pages: write"」：デプロイのジョブに
pages: writeとid-token: writeが要ります。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、タイムアウトしたデプロイのジョブと、その後ろで Queued のままの実行が並んで見え、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub・GitHub Actions・GitHub Pages は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：止まらない実行と force-cancel · 「Get Pages site failed」 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English