GitHub ActionsやWebhooksに約1時間の障害 10月は12件目

GitHubは、日本時間2026年10月20日0時49分から1時56分ごろまで、GitHub Actions、GitHub Pages、Webhooksの可用性が落ちたと公表しました。ワークフローの処理やサイトの作成、Webhookの配信が遅れましたが、すでに解消しています。GitHubの状況ページで、10月の障害は12件目です。

状況ページに書かれた経過

GitHubの状況ページの記録は、次のとおりです(時刻は協定世界時(UTC)と日本時間)。

GitHubは、詳しい原因の分析(根本原因の分析)を、まとまり次第出すとしています。原因と、影響を受けた利用者の数は、まだ書かれていません。

10月の障害は12件目

GitHubの状況ページの障害の記録を、10月1日から数えると、今回で12件目です。状況ページは障害ごとに影響の大きさを付けていて、今回は最も重い「critical」です。10月の「critical」は、10月5日、6日、7日(2件)に続いて5件目です。

10月12日の障害は、GitHubでActions・Issues・PRに障害、10月は9件目。開発が止まったときの確認にまとめています。その後、10月13日と15日に小さな障害の記録があり、今回が12件目です。

取りこぼした通知は、手で送り直す

今回の障害では、Webhookの配信も遅れました。Webhookは、GitHubで起きたことを、ほかのツール(チャット、チケットの管理、デプロイの仕組みなど)へ知らせる仕組みです。

GitHubの説明によると、失敗したWebhookの配信は、自動では送り直されません。過去3日以内の配信は、Webhookの設定の「Recent deliveries」から選んで、手で送り直せます。リポジトリのWebhookはリポジトリの管理者が、組織のWebhookは組織の所有者が操作できます。REST APIでも送り直せます。

影響する会社・しない会社

• 影響する: GitHub Actionsで、テストやデプロイ、定期の作業を動かしている会社です。日本時間0時49分から1時56分ごろの実行が、遅れたり、状態の更新が遅れたりしました。
• 影響する: GitHub Pagesで、社内外のサイトや資料を公開している会社です。その時間のサイトの作成が遅れました。
• 影響する: Webhookで、GitHubとチャットやチケット、デプロイの仕組みをつないでいる会社です。通知が遅れたり、届かなかったりした可能性があります。
• 影響しない: その時間にGitHubの自動の処理や連携を動かしていなかった会社です。Gitの操作やプルリクエストの障害は、今回の記録には書かれていません。

情シスが今日やること

1. 夜間の自動の処理の結果を確かめます。 日本時間0時から2時ごろに動いたActionsのワークフローを、Actionsのタブで見て、失敗や止まったままのものを再実行します。
2. デプロイが反映されたかを確かめます。 その時間にPagesやActionsで公開したサイトやアプリが、新しい版になっているかを見ます。
3. Webhookの配信を確かめ、必要なら送り直します。 連携しているツールで通知が抜けていないかを見て、抜けていれば「Recent deliveries」から送り直します。3日を過ぎると送り直せないので、今日中に済ませます。
4. 原因の分析が出たら読む担当を決めます。 GitHubは、詳しい原因の分析をあとで出すとしています。同じ型の障害への備えが要るかを判断します。
5. 障害が続くときの代わりの手順を見直します。 10月は12件目です。急ぎのデプロイを手で行う手順や、状況ページの通知を受け取る設定(Subscribe to Updates)を確かめます。

2026年10月20日時点の内容です。