GitHub可用性レポート：2026年2月

**タイトル: GitHub 可用性レポート: 2026年2月** 2月、GitHubサービスの広範囲でパフォーマンス低下を引き起こした6件のインシデントが発生しました。 これらの障害が、チームやワークフロー、そして当社プラットフォームへの全体的な信頼に与えた影響を認識しています。本日早朝、最近のインシデントの根本原因と、GitHubがシステムの回復力を高めるために講じている措置について概説したブログ記事を公開しました。当社が近期的および長期的な投資に取り組む間、ご忍耐いただきありがとうございます。 以下、2月に発生した6件の主要なインシデントについて説明します。 **2月2日 17:41 UTC (継続時間 1時間5分)** 2026年1月31日 00:30 UTCから2026年2月2日 18:00 UTCまで、Dependabotサービスのパフォーマンスが低下し、自動プルリクエストの10%の作成に失敗しました。これは、読み取り専用データベースに接続したクラスターのフェイルオーバーが原因でした。 トラフィックが正常なクラスターに適切にルーティングされるまでDependabotキューを一時停止することで、インシデントを軽減しました。すべての失敗したジョブを特定し、再起動しました。 検出時間を短縮し、将来の再発を防止するため、新たなモニターとアラートを追加しました。 **2月2日 19:03 UTC (継続時間 5時間53分)** 2026年2月2日 18:35 UTCから22:20 UTCの間、GitHub ActionsのホステッドランナーとGitHub Codespacesが利用不可となり、サービスは完全回復まで低下した状態が続きました。標準ランナーは2026年2月3日 23:10 UTCに、大規模ランナーは同年2月3日 00:30 UTCに、Codespacesは2月3日 00:15 UTCにそれぞれ完全回復しました。この間、Actionsジョブはキューイングされ、ホステッドランナーの取得待ちでタイムアウトしました。このコンピュートインフラストラクチャを利用する他のGitHub機能も同様に影響を受けました。これにはCopilotコーディングエージェント、Copilotコードレビュー、CodeQL、Dependabot、GitHub Enterprise Importer、GitHub Pagesが含まれます。すべてのリージョンとランナータイプが影響を受けました。Codespacesの作成と再開操作もすべてのリージョンで失敗しました。他のプロバイダー上のActions用セルフホステッドランナーは影響を受けませんでした。 この障害は、テレメトリの消失が連鎖し、基盤となるコンピュートプロバイダーのバックエンドストレージアカウントに対して誤ってセキュリティポリシーが適用されたことが原因でした。これらのポリシーは重要なVMメタデータへのアクセスをブロックし、すべてのVMの作成、削除、再イメージ化、その他の操作を失敗させました。詳細情報は[こちら](https://github.com/blog/...)で入手できます。このインシデントは、22:15 UTCに開始したポリシー変更のロールバックにより軽減されました。VMがオンラインに戻るにつれ、当社のランナーはタイムアウトしていなかったリクエストのバックログを処理しました。 当社はコンピュートプロバイダーと協力し、インシデント対応とエンゲージメント時間の改善、早期検出の向上、将来同様の変更が発生した場合の安全なロールアウトを確保する取り組みを行っています。 **2月9日 16:19 UTC (継続時間 1時間21分) および 2月9日 19:01 UTC (継続時間 1時間8分)** 2026年2月9日、GitHubはgithub.com、GitHub API、GitHub Actions、Git操作、GitHub Copilot、その他のサービスに影響を与える、関連する2回の可用性低下期間を経験しました。最初の期間は16:12 UTCから17:39 UTCの間、2回目は18:53 UTCから20:09 UTCの間に発生しました。合計で、ユーザーは2件のインシデントにわたって約2時間43分のサービス低下を経験しました。 両方のインシデント中、ユーザーはgithub.comでのページ読み込みエラー、HTTPS経由でのコードのプッシュまたはプル時の失敗、GitHub Actionsワークフロー実行の開始または完了の失敗、GitHub Copilot使用時のエラーに遭遇しました。GitHub Issues、プルリクエスト、ウェブフック、Dependabot、GitHub Pages、GitHub Codespacesを含む追加サービスも断続的なエラーを発生させました。SSHベースのGit操作はどちらのインシデント中も影響を受けませんでした。 調査の結果、両方のインシデントは同じ根本原因を共有していると判断しました。ユーザー設定キャッシュメカニズムへの設定変更により、大量のキャッシュ書き換えが同時に発生しました。最初のインシデントでは、非同期書き換えが、バックグラウンド作業の調整を担当する共有インフラストラクチャコンポーネントを圧倒し、HTTPS経由のGit操作をプロキシするサービスでの連鎖的障害と接続枯渇につながりました。非同期キャッシュ書き換えを無効化し、影響を受けたGitプロキシサービスを複数のデータセンターで再起動することで、このインシデントを軽減しました。 2回目のインシデントは、初期の軽減策で対処されなかった追加のキャッシュ更新ソースが、大量の同期書き込みを引き起こしたときに発生しました。これによりレプリケーション遅延が生じ、同様の連鎖的障害を引き起こし、再びGit HTTPSプロキシでの接続枯渇につながりました。キャッシュ書き換えのソースを無効化し、再びGitプロキシを再起動することで軽減しました。 当社は以下の即時措置を講じています： * キャッシュメカニズムを最適化して書き込み増幅を回避し、一括更新時の自己スロットリングを追加しました。 * キャッシュメカニズムがロールバックにより迅速に対応することを保証する保護策を追加し、これらのキャッシュシステムへの変更が追加チェックとともに計画、検証、ロールアウトされる方法を強化しています。 * Git HTTPSプロキシレイヤーにおける接続枯渇の根本原因を修正し、プロキシが手動再起動を必要とせずにこの障害モードから自動的に回復できるようにしています。 **2月12日 07:53 UTC (継続時間 2時間3分)** 2026年2月12日 00:51 UTCから09:35 UTCの間、Codespacesの作成または再開を試みるユーザーは、ヨーロッパ、アジア、オーストラリア全体で障害率が上昇し、ピーク時には90%の障害率に達しました。影響はUK Southで開始し、他のリージョンに徐々に広がりました。米国リージョンは影響を受けませんでした。 障害は、コアネットワーク依存関係での認証要求変更が原因で、Codespaceプールのプロビジョニング失敗につながりました。アラートは問題を検出しましたが適切な重大度が設定されておらず、検出と対応が遅れました。この教訓を活かし、当社はこのバックエンドサービスへの変更の検証とロールアウト中の監視を改善しました。アラートのしきい値も更新され、顧客に影響を与える前に問題を捕捉できるようにし、この領域をカバーする自動フェイルオーバーメカニズムを改善しました。 **2月12日 10:38 UTC (継続時間 34分)** 2026年2月12日 09:16から11:01 UTCの間、Git LFSオブジェクトを含むリポジトリアーカイブ（tar.gz/zip）のダウンロードを試みるユーザーはエラーを受け取りました。LFSオブジェクトを含まない標準のリポジトリアーカイブは影響を受けませんでした。平均して、アーカイブダウンロードのエラー率はサービスへのリクエストの0.0042%で、ピーク時は0.0339%でした。これは、LFSサービスでの誤ったネットワーク構成のデプロイメントが原因で、サービスのヘルスチェックが失敗し、内部サービスが誤って到達不能とマークされたためです。 修正されたネットワーク設定を手動で適用することで、インシデントを軽減しました。この種の構成問題を防ぐために、破損の追加チェックと自動ロールバック検出が追加されました。 ステータス変更とインシデント後の概要のリアルタイム更新については、[ステータスページ](https://www.githubstatus.com/)をフォローしてください。当社の取り組みについて詳しく知りたい場合は、[GitHubブログのエンジニアリングセクション](https://github.blog/category/engineering/)をご覧ください。 *この投稿 GitHub availability report: February 2026 は The GitHub Blog に最初に掲載されました。*

GitHub可用性レポート：2026年2月

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト