GitHubは2026年10月12日21時21分(日本時間)、Actions・Issues・Pull Requestsで性能の低下が起きていると、公式の稼働状況ページ(GitHub Status)で公表しました。影響の区分は「minor」(軽度)です。10月12日21時52分の時点で、状態は「Investigating」(調査中)で、復旧の表示は出ていません。
稼働状況ページに載った10月の障害は、これで9件目です。うち4件は、最も重い区分の「critical」でした。この記事は、GitHubの稼働状況ページとそのデータで確かめた範囲を書きます。
公式の資料で確かめられたこと
| 項目 |
内容 |
| 題 |
Incident with Actions, Pull Requests and Issues |
| 始まり |
10月12日21時21分(日本時間。UTCでは12時21分) |
| 影響の区分 |
minor。Actions・Issues・Pull Requestsの3つが「Degraded Performance」(性能の低下) |
| 起きること(21時33分の更新) |
Actionsのタブの表示、Checks APIの利用、新しいActionsの実行の受け付け、Issueの作成と更新、PRのレビュー依頼で、問題が出ることがある。REST・GraphQLのAPI経由も含む |
| 状態 |
10月12日21時52分(日本時間)の時点で「Investigating」(調査中) |
| 原因 |
書かれていません |
GitHubの稼働状況ページの今回の障害の項目(10月12日21時49分ごろ・日本時間に撮影。表示の時刻はUTC)出典: GitHub「GitHub Status」(引用)
Gitの操作(pushやclone)は、今回の対象に挙がっていません。10月7日(UTC)の2件の障害では、Gitの操作も対象でした。
10月の障害は9件目
稼働状況ページのデータ(公開のAPI)から、10月1日以降の掲載を並べます。時刻は日本時間に直しています。「続いた時間」は、ページへの掲載から「解決」までの時間です。
| 始まり(日本時間) |
題 |
区分 |
続いた時間 |
対象 |
| 10月1日 11時00分 |
[Retroactive] Actions workflow run failures after deployment gate approvals |
minor |
あとから掲載 |
Actionsの一部の実行 |
| 10月1日 22時37分 |
Elevated request latency |
minor |
約20分 |
GitHub.comの表示 |
| 10月1日 23時47分 |
Actions Job Delays |
minor |
約3時間9分 |
Actions |
| 10月6日 4時11分 |
Incident with Actions |
critical |
約3時間38分 |
Actions・Pages |
| 10月6日 8時47分 |
Disruption with some GitHub services |
major |
約1時間45分 |
組織の請求・ライセンス・設定のページ |
| 10月7日 4時57分 |
Several services are degraded |
critical |
約3時間43分 |
Webhooks・Pull Requests |
| 10月8日 0時14分 |
Incident with Git Operations, Pull Requests and Actions |
critical |
約1時間10分 |
Git操作・Webhooks・Issues・Pull Requests・Actions |
| 10月8日 2時17分 |
Incident with Git Operations, Issues, Actions and Pull Requests |
critical |
約48分 |
Git操作・Issues・Pull Requests・Actions |
| 10月12日 21時21分 |
Incident with Actions, Pull Requests and Issues |
minor |
継続中(21時52分の時点) |
Issues・Pull Requests・Actions |
区分は、criticalが4件、majorが1件、minorが4件です。9件のうち6件で、Actionsが対象になっています。9件のうち7件は、日本時間の22時から翌朝9時までに始まりました。今回は21時台です。
比べるために9月を数えると、UTCの日付で1か月に14件、うちcriticalは2件でした。10月は、12日までで9件、criticalは4件です。
公式が書いている原因
GitHubは、解決のあとに原因のまとめを載せることがあります。10月の9件のうち、まとめが載っているのは5件です。
- 10月6日 4時11分からのActionsの障害: 自社のデータセンターの一部の地域と、クラウドの地域ごとのデータベース・ストレージの間で、ネットワークの一部が切れたことが原因です。影響が最も大きかった約90分間は、GitHubが用意するランナーを使う実行の47.0%が失敗し、ジョブの71.9%が5分以内に始まりませんでした。セルフホストのランナーは影響を受けなかったと書かれています
- 10月6日 8時47分からの障害: 同じくネットワークの障害が原因です。組織やEnterpriseの請求・ライセンス・設定のページで、エラーの割合が平均1.9%、最大13.8%になりました
- 10月1日のActionsの遅れ: クラウド事業者の経路の変更で通信が1か所に集まり、制限に当たるエラーが増えたことが発端です。実行の約0.68%で開始が遅れ、ジョブの0.196%が始まりませんでした
- 10月1日の表示の遅れ: 通常より多い通信が届いたことが原因です。エラーの割合は平均0.52%、最大6.13%でした
- 10月1日の、あとから掲載された件: 設備の障害で、一部の実行の状態が失われました。止まったままの実行は、新しく実行し直すか、GitHubのサポートに連絡するよう案内しています
10月7日と8日(日本時間)のcriticalの3件は、「詳しい原因の分析は、用意ができしだい共有する」と書かれたままです。10月12日の時点で、分析は載っていません。
影響する会社・しない会社
- 影響する: GitHub.comでコードを管理し、Actionsでテスト・ビルド・デプロイを自動化している会社
- 影響する: IssuesやPull Requestsを、作業の管理やレビューに使っている会社。作成、更新、レビュー依頼がうまくいかないことがあります
- 影響する(確認が要る): 開発や保守を外部に委託していて、委託先がGitHubを使っている会社。納品やリリースの遅れとして出ることがあります(編集部の補足)
- 影響する(確認が要る): GitHubのAPIを使う社内の仕組み(チャットへの通知、課題の自動登録など)がある会社
- 影響しない: GitHubを使っていない会社
- 影響しない(一般的な整理): 自社のサーバーで動かすGitHub Enterprise Serverだけを使っている会社。稼働状況ページが扱うのは、GitHubが運用するサービスです
情シスが今日やること
- 公式の稼働状況ページ(githubstatus.com)で、今の状態を確かめる。「GitHubが遅い」と連絡が来たら、社内の回線を疑う前にここを見ます。「Subscribe to Updates」で、メールやSlackに更新が届くようにしておきます
- 止まっている実行と失敗した実行を、開発の担当者に洗い出してもらう。やり直しは、復旧の表示を見てからにします。デプロイを含むワークフローは、やり直す前に、途中まで済んだ手順が無いかを確かめます(10月1日の公式の案内と同じ考え方です)
- 今日と明日のリリースや締め切りを確かめ、延ばすかを担当者と決める。急ぎのリリースを手作業に切り替えるときは、だれが何を実行したかを残します(編集部の補足)
- 委託先に、納期や作業への影響を聞く。障害の時間帯と、止まった作業を文書で返してもらいます
- 影響を記録する。いつからいつまで、どの作業が止まったかを書きます。10月は障害が続いているので、月末に件数と止まった時間を振り返れるようにします。損失の目安は業務停止の損失シミュレーターでも出せます
書かれていないこと
次の点は、確かめた資料には書かれていません。この記事でも書きません。
- 今回の障害の原因と、影響を受けた利用者の割合
- 10月7日・8日(日本時間)のcriticalの3件の原因
- 一連の障害に、共通の原因があるかどうか
- 日本の利用者への影響の程度
- 有償のプランでの、稼働率の保証や返金の扱い(契約の文書は確かめていません)
