GitHubは、日本時間2026年10月21日の深夜から22日の明け方にかけて、プルリクエストの更新、Webhookの配信、Actionsのワークフローの状態の更新が遅れたと、状況ページで公表しました。監査ログのイベントは、最大110分遅れました。すでに解消しています。GitHubを開発や運用の自動化に使い、監査ログを監視の仕組みに取り込んでいる会社は、その時間の取りこぼしを確かめます。
GitHubの状況ページ。22日4時22分(日本時間)に解決とした(英語)出典: GitHub Status「Delays for Pull Requests and Webhook deliveries」(引用)
状況ページに書かれた経過
状況ページの影響の大きさは、最も重い「critical」で、対象はWebhooks、Pull Requests、Actionsです(時刻は日本時間)。
- 10月21日23時52分: Actions、プルリクエスト、Webhookの性能の低下を調べ始める
- 22日0時36分: イベントを流す基盤の負荷が増え、偏りが出ていると説明。処理を別の場所に移し、処理の力を足している
- 0時58分: プルリクエストの更新、Webhookの配信に加え、監査ログのイベントも遅れている
- 1時25分: 監査ログのイベントは最大100分遅れ。Actionsのワークフローの状態の更新も大きく遅れている
- 1時33分: プルリクエストは正常に
- 1時34分: 監査ログのイベントは最大110分遅れ
- 1時57分: ActionsとWebhookは正常に
- 2時09分: 監査ログの残りの処理に2〜3時間かかる見込み
- 3時52分: 監査ログの遅れは70分未満に
- 4時22分: 監査ログの遅れは40分未満で正常な範囲に戻り、解決とした
途中の更新。監査ログのイベントは最大110分遅れた(英語)出典: GitHub Status「Delays for Pull Requests and Webhook deliveries」(引用)
詳しい原因の分析は、まとまり次第出すとしています。
10月の障害は13件目
GitHubの状況ページの障害の記録を10月1日から数えると、今回で13件目です。最も重い「critical」は、10月5日、6日、7日(2件)、19日(日本時間20日)に続いて6件目です。前回の障害は、GitHub ActionsやWebhooksに約1時間の障害 10月は12件目にまとめています。日本時間の20日と22日、3日のうちに2回、Webhookの配信が遅れたことになります。
監査ログが遅れた間の、監視の穴
今回の特徴は、監査ログのイベントが最大110分遅れたことです。監査ログを、SIEM(ログを集めて怪しい動きを見つける仕組み)などに取り込んで見張っている会社では、次のことが起こりえます(当社の見立て)。
- 決まった時間の幅で集計する検知の決まりで、遅れて届いたイベントが数えられず、警報が出なかった
- 監視の仕組みが、イベントの起きた時刻ではなく届いた時刻で記録し、時刻がずれて残った
- 「何分ログが来なかったら警報」という見張りが、障害の間に鳴った
権限の変更、リポジトリの公開の設定、外部への招待など、見逃すと困る操作の検知の結果を、その時間について見直しておくと安心です。
Webhookは、失敗したものを自動では送り直さない
今回のWebhookは「遅れ」で、GitHubは積み残しを処理して届けたとしています。一方、GitHubの説明では、配信に失敗したWebhookは自動では送り直されません。受け取る側のサーバーが、その時間に時間切れなどで失敗を返していた場合は、手で送り直す必要があります。
- 送り直せるのは、過去3日の配信
- リポジトリのWebhookを送り直せるのは、リポジトリの管理者の権限を持つ人
- 画面(Webhookの設定の「Recent Deliveries」)か、REST APIで送り直せる
遅れて届いた配信は、順番が入れ替わったり、送り直しで同じものが2回届いたりします。受け取る側が、同じ配信を2回処理しないように作られているかも確かめておきます(当社の見立て)。
影響する会社・しない会社
- 影響する: GitHubの監査ログを、SIEMや監視の仕組みに取り込んでいる会社です。その時間のイベントの遅れが、検知に影響していないかを確かめます。
- 影響する: Webhookで、GitHubとチャット、チケット、デプロイの仕組みをつないでいる会社です。届かなかった通知や、止まった連携がないかを見ます。
- 影響する: Actionsで、テストやデプロイを動かしている会社です。状態の更新が遅れたため、結果の確認や、続きの処理の始まりが遅れた可能性があります。
- 影響しない: その時間にGitHubの自動の処理や連携を動かしておらず、監査ログも取り込んでいない会社です。
情シスが今日やること
- 監査ログの検知を見直す。 日本時間10月21日23時50分から22日4時半ごろまでの、GitHubの監査ログの取り込みと検知の結果を確かめます。遅れて届いたイベントが、検知の決まりで正しく扱われたかを見ます。
- Webhookの失敗を送り直す。 社内の連携に使っているWebhookの「Recent Deliveries」で、その時間に失敗したものがないかを見て、あれば送り直します。期限は3日です。
- Actionsの結果を確かめる。 夜間に動いたテストやデプロイが、最後まで終わったかを確かめます。状態の更新の遅れで、同じデプロイが2回動いていないかも見ます。
- 原因の分析を待つ。 GitHubが詳しい原因の分析を出したら、再発の防ぎ方と、自社の連携で備えることを見直します。障害が続いているため、GitHubが止まったときの手順(手でのデプロイ、別の通知の手段)を用意しておきます。
