GitHubの信頼性レポートカード：1,125件のインシデントと数える

新しいサイドプロジェクト、Is GitHub Cooked?は、GitHub自身のステータスページがやらないことをやる：数年にわたるインシデント履歴を、フィルタリング可能なサービス別信頼性レポートカードに変える。このサイトはGitHubの公開インシデントデータを2016年3月まで遡って取得し、サービス、重大度、期間でスライスできる。

見出しの数字は冷静になる。GitHubは2016年以来1,125件のインシデントを記録し、過去3ヶ月で平均月24件（前四半期比5%減）。インシデントなしの最長期間はわずか8日で、2025年12月31日に終了。2026年2月は37件で記録上最悪の月だった。

CopilotとActionsが弱点

サービス可用性テーブル（直近3ヶ月）は明確な物語を語る：AI中心とCI/CDワークロードが最も脆弱だ。Copilotは稼働率97.93%（ダウンタイム7日13時間）で最下位、次いでActionsが98.21%（6日12時間）。Pull Requests、Search、Webhooksが下位5位を占める。

一方、コアなリポジトリ操作ははるかに健全：Repositories、Gists、Dashboardはすべて99.9%以上で、Dashboard、Discussions、Docs、Mobileは完璧な100%だ。

重大度と解決パターン

重大度の内訳では、インシデントの81%がMinor、17%がMajor、わずか2%がCriticalと分類される。これは多くのノイズだが、累積効果は重要だ：マイナーなインシデントでもCIパイプラインを壊したり、PRをブロックしたりできる。

インシデント数が最悪だった日は2026年2月9日で7件。生のダウンタイムが最悪だった日は2025年4月16日で、累積ダウンタイム1日2時間。水曜日と火曜日が最もインシデントが発生しやすい日で、週末は比較的静かだ。

これはあなたのSLOに何を意味するか

GitHub ActionsやCopilot上に構築しているなら、あなた自身の信頼性の物語はGitHubのそれに結びついている。Actionsの稼働率98%は、断続的な障害—リトライ、フォールバックランナー、そしてすべての小さな変動でページングしないアラート—を設計する必要があることを意味する。

このサイトの価値は、これらのトレードオフを明確にすることにある。実際に依存しているサービスでフィルタリングし、独自の重大度しきい値を設定できるので、git操作だけを気にする同僚と、Copilotの障害と戦いながら議論する必要がない。

これは「GitHubがダウン」が単一のイベントであることはまれで、チームごとに異なる影響を与えるサービス固有の障害のスペクトラムであることを思い出させる。