GitHubは2026年9月13日、API Requests、Issues、Pull Requests、Actions、Pagesなど複数サービスでシステム障害が発生したと公表しました。
GitHub Statusによると、障害は同日9時16分UTC、日本時間18時16分頃に公表され、10時44分UTC、日本時間19時44分頃に復旧しました。公表から復旧までの時間は約1時間28分です。
障害対応中、GitHubは「collab」でデータベースのレプリケーション遅延が増加し、認可関連エンドポイントのエラー率が上昇した結果、システム全体でエラーが増えていると説明しました。
その後、対象クラスタへの負荷を内部のload-sheddingで軽減し、回復傾向を確認しました。10時44分UTCに障害解消を公表しています。
9月13日時点では詳細な根本原因分析(RCA)はまだ公開されていません。GitHubは今後、詳細なRCAを共有するとしています。
GitHubシステム障害のサマリー
- 2026年9月13日9時16分UTC、日本時間18時16分頃、GitHubが複数サービスの可用性低下を公表しました。
- 影響を受けたサービスはAPI Requests、Issues、Pull Requests、Actions、Pagesです。
- 9時25分UTCにはGitHub Actionsのパフォーマンス低下も公表されました。
- 9時36分UTC、collabのデータベースレプリケーション遅延が増加し、認可エンドポイントのエラー率とシステム全体のエラー率が上昇していると説明しました。
- 10時26分UTC、内部のload-sheddingによって対象クラスタの負荷を削減し、回復傾向を確認しました。
- 10時28分UTC時点ではPull Requestsでパフォーマンス低下が継続していました。
- 10時44分UTC、日本時間19時44分頃に障害は解消しました。
- 公表から復旧まで約1時間28分です。
- 詳細な根本原因分析は9月13日時点で未公表です。
- 不正アクセスやサイバー攻撃が原因との説明はありません。
| 項目 | 内容 |
|---|---|
| 発生日 | 2026年9月13日 |
| 障害公表 | 9時16分UTC(日本時間18時16分頃) |
| 復旧 | 10時44分UTC(日本時間19時44分頃) |
| 公表から復旧まで | 約1時間28分 |
| 影響サービス | API Requests、Issues、Pull Requests、Actions、Pages |
| 障害中に確認された事象 | collabのDBレプリケーション遅延、認可エンドポイントのエラー増加 |
| 対応 | 内部load-sheddingでクラスタ負荷を低減 |
| 根本原因 | 詳細RCAは未公表 |
| サイバー攻撃 | 公表なし |
API Requests、Issues、Pull Requests、Actions、Pagesで障害
GitHubは9月13日9時16分UTC、API Requests、Issues、Pages、Pull Requestsで可用性低下の報告を調査していると公表しました。
9分後の9時25分UTCには、GitHub Actionsでもパフォーマンス低下が発生していると更新しています。
GitHub Statusで最終的に影響サービスとして列挙されたのは、API Requests、Issues、Pull Requests、Actions、Pagesの5つです。
これらはソースコード管理だけでなく、CI/CD、開発チームのレビュー、課題管理、Web公開などにも利用されます。
GitHub Actionsをデプロイパイプラインに組み込んでいる企業では、Actionsの遅延やエラーがビルド、テスト、デプロイの遅延につながる可能性があります。
データベースのレプリケーション遅延と認可系エラーを確認
9時36分UTC、GitHubは障害調査の途中経過として、collabでデータベースレプリケーション遅延が増加していると説明しました。
この遅延によって認可関連エンドポイントのエラー率が上昇し、その後システム全体でエラー率が増えているとしています。
ただし、これは障害対応中にGitHubが確認した状況です。
9月13日時点では詳細な根本原因分析は公開されていないため、「データベースレプリケーション遅延そのものが最終的な根本原因だった」とまでは断定できません。
load-sheddingでクラスタ負荷を低減し回復
10時26分UTC、GitHubは内部のload-sheddingによって対象クラスタへの負荷を減らし、回復の兆候が見られていると公表しました。
ただし、10時28分UTCの更新ではPull Requestsでパフォーマンス低下が続いていました。
その後、10時44分UTCにGitHubはインシデントの解消を公表しました。
GitHubは利用者へ謝意を示したうえで、詳細な根本原因分析を準備し、利用可能になり次第公開するとしています。
GitHubは8月にも複数の大規模障害を公表
GitHubは9月9日に公開した2026年8月のAvailability Reportで、8月に5件のサービス障害が発生したと報告しています。
8月6日にはGitHub Actionsで長時間の障害が発生しました。また、8月17日にはgithub.com、認証、GitHub Actions、API、Pull Requests、Issues、Copilotなど複数サービスへ影響する障害が発生しています。
GitHubによると、8月17日の障害は約7時間47分続きました。Central USデータセンターの重要インフラがトラフィック増加に追いつけず、容量不足が複数サービスへ波及したことが原因でした。
GitHubは8月の障害を受け、容量監視、オートスケーリング、リトライ制御、サービスの耐障害性などを改善しています。
今回9月13日に発生した障害について、8月の容量問題と同じ原因かどうかは公表されていません。
GitHub障害時に情報システム・開発部門が確認したいこと
GitHubを開発基盤として利用している企業では、GitHub自体の障害を完全に防ぐことはできません。
そのため、外部SaaS障害を前提に、業務への影響を限定する設計が必要です。
- GitHub Actionsが停止した場合に、どのビルド・テスト・デプロイが止まるか把握しているか
- GitHub APIエラー時に社内システムが過剰なリトライを行わない設計になっているか
- デプロイが必要な緊急時に代替手順を用意しているか
- Gitリポジトリをローカルまたは別環境へ複製できる状態か
- GitHub Pagesを重要な業務サイトの唯一の配信経路にしていないか
- GitHub Statusを監視し、インシデント発生時に開発・運用担当へ通知できるか
- SaaS障害と自社側の設定・ネットワーク障害を切り分ける手順があるか
- 復旧後に滞留したジョブや失敗したWebhookを確認・再実行できるか
GitHub ActionsをCI/CDの唯一の実行経路としている場合、GitHub側の障害が自社サービスのリリースや緊急修正を止める可能性があります。
外部SaaSの可用性を自社のBCP・開発運用設計へ含めておく必要があります。
GitHubに関連するセキュリティインシデントについては、GitHubの内部リポジトリへの不正アクセス、VS Code拡張機能から侵害でも整理しています。








