GitHub可用性レポート：2026年2月
GitHubは2026年2月に発生した6件のインシデント（Dependabotの障害、GitHub Actions/Codespacesの大規模障害を含む）について詳細なレポートを公開し、原因分析と再発防止策を説明した。
キーポイント
2月の主要インシデント6件
GitHubは2026年2月に6件のインシデントを経験し、サービスのパフォーマンス低下を引き起こした。特に2月2日の大規模障害は複数のサービスに影響を与えた。
大規模障害の原因と影響範囲
2月2日の障害はテレメトリの喪失が原因で、セキュリティポリシーが誤って適用され、GitHub Actions、Codespaces、Copilot、CodeQLなど複数のサービスが5時間以上利用不能になった。
根本原因と対応策
各インシデントについて技術的原因を特定し、モニタリング強化、ポリシーロールバック、コンピュートプロバイダーとの連携改善などの対策を実施した。
透明性と信頼回復の取り組み
GitHubは詳細な障害レポートを公開し、影響を受けたチームへの謝罪とともに、システムのレジリエンシー向上に向けた短期的・長期的な投資を約束している。
GitHubサービスの可用性低下
2026年2月9日に2回の可用性低下が発生し、github.com、GitHub API、GitHub Actions、Git Copilotなど複数サービスに影響。合計約2時間43分のサービス低下。
根本原因と対応
ユーザー設定キャッシュメカニズムの設定変更が原因で、キャッシュ書き換えが大量発生。非同期書き換えと同期書き換えの両方がGit HTTPSプロキシの接続枯渇を引き起こした。
追加のサービス障害
2月12日にCodespacesの作成・再開で障害が発生。欧州、アジア、オーストラリアで最大90%の失敗率。米国地域は影響なし。
影響分析・編集コメントを表示
影響分析
このレポートは、GitHubのような重要な開発者プラットフォームにおける信頼性の重要性を浮き彫りにしている。特にAI支援開発ツール（Copilot）の普及が進む中で、基盤インフラの安定性が開発者の生産性に直接影響を与えることを示している。透明性の高い障害報告は、プラットフォームの信頼回復と長期的なユーザー維持に不可欠な取り組みと言える。
編集コメント
大規模開発者プラットフォームの障害事例として、AIツールを含む現代の開発ワークフローがいかにインフラの安定性に依存しているかを示す貴重なケーススタディ。
タイトル: 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の作成、削除、再イメージ化、その他の操作を失敗させました。詳細情報はこちらで入手できます。このインシデントは、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サービスでの誤ったネットワーク構成のデプロイメントが原因で、サービスのヘルスチェックが失敗し、内部サービスが誤って到達不能とマークされたためです。
修正されたネットワーク設定を手動で適用することで、インシデントを軽減しました。この種の構成問題を防ぐために、破損の追加チェックと自動ロールバック検出が追加されました。
ステータス変更とインシデント後の概要のリアルタイム更新については、ステータスページをフォローしてください。当社の取り組みについて詳しく知りたい場合は、GitHubブログのエンジニアリングセクションをご覧ください。
*この投稿 GitHub availability report: February 2026 は The GitHub Blog に最初に掲載されました。*
原文を表示
In February, we experienced six incidents that resulted in degraded performance across GitHub services.
We recognize the impact these outages have had on teams, workflows, and overall confidence in our platform. Earlier today, we released a blog post outlining the root causes of recent incidents and the steps GitHub is taking to make our systems more resilient moving forward. Thank you for your patience as we work through near-term and long-term investments we’re making.
Below, we go over the six major incidents specific to February.
February 02 17:41 UTC (lasting 1 hour and 5 minutes)
From January 31, 2026, 00:30 UTC, to February 2, 2026, 18:00 UTC, Dependabot service was degraded and failed to create 10% of automated pull requests. This was due to a cluster failover that connected to a read-only database.
We mitigated the incident by pausing Dependabot queues until traffic was properly routed to healthy clusters. All failed jobs were identified and restarted.
We added new monitors and alerts to reduce our time to detect and prevent this in the future.
February 02 19:03 UTC (lasting 5 hours and 53 minutes)
On February 2, 2026, between 18:35 UTC and 22:20 UTC, GitHub Actions hosted runners and GitHub Codespaces were unavailable, with service degraded until full recovery at 23:10 UTC for standard runners, February 3, 2026 at 00:30 UTC for larger runners, and February 3 at 00:15 for codespaces. During this time, actions jobs queued and timed out while waiting to acquire a hosted runner. Other GitHub features that leverage this compute infrastructure were similarly impacted, including Copilot coding agent, Copilot code review, CodeQL, Dependabot, GitHub Enterprise Importer, and GitHub Pages. All regions and runner types were impacted. Codespaces creation and resume operations also failed in all regions. Self-hosted runners for actions on other providers were not impacted.
This outage was caused by a loss in telemetry that cascaded to mistakenly applying security policies to backend storage accounts in our underlying compute provider. Those policies blocked access to critical VM metadata, causing all VM create, delete, reimage, and other operations to fail. More information is available here. This was mitigated by rolling back the policy changes, which started at 22:15 UTC. As VMs came back online, our runners worked through the backlog of requests that hadn’t timed out.
We are working with our compute provider to improve our incident response and engagement time, improve early detection, and ensure safe rollout should similar changes occur in the future.
February 09 16:19 UTC (lasting 1 hour and 21 minutes) and February 09 19:01 UTC (lasting 1 hour and 8 minutes)
On February 9, 2026, GitHub experienced two related periods of degraded availability affecting github.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other services. The first period occurred between 16:12 UTC and 17:39 UTC, and the second between 18:53 UTC and 20:09 UTC. In total, users experienced approximately 2 hours and 43 minutes of degraded service across the two incidents.
During both incidents, users encountered errors loading pages on github.com, failures when pushing or pulling code over HTTPS, failures starting or completing GitHub Actions workflow runs, and errors using GitHub Copilot. Additional services including GitHub Issues, pull requests, webhooks, Dependabot, GitHub Pages, and GitHub Codespaces experienced intermittent errors. SSH-based Git operations were not affected during either incident.
Our investigation determined that both incidents shared the same underlying cause: a configuration change to a user settings caching mechanism caused a large volume of cache rewrites to occur simultaneously. In the first incident, asynchronous rewrites overwhelmed a shared infrastructure component responsible for coordinating background work, which led to cascading failures and connection exhaustion in the service proxying Git operations over HTTPS. We mitigated this incident by disabling async cache rewrites and restarting the affected Git proxy service across multiple datacenters.
The second incident arose when an additional source of cache updates, not addressed by the initial mitigation, introduced a high volume of synchronous writes. This caused replication delays, resulting in a similar cascade of failures and again leading to connection exhaustion in the Git HTTPS proxy. We mitigated by disabling the source of the cache rewrites and again restarting Git proxy.
We are taking the following immediate steps:
We optimized the caching mechanism to avoid write amplification and added self-throttling during bulk updates.
We are adding safeguards to ensure the caching mechanism responds more quickly to rollbacks and strengthening how changes to these caching systems are planned, validated, and rolled out with additional checks.
We are fixing the underlying cause of connection exhaustion in our Git HTTPS proxy layer so the proxy can recover from this failure mode automatically without requiring manual restarts.
February 12 07:53 UTC (lasting 2 hours and 3 minutes)
On February 12, 2026, between 00:51 UTC and 09:35 UTC, users attempting to create or resume Codespaces experienced elevated failure rates across Europe, Asia, and Australia, peaking at a 90% failure rate. Impact started in UK South and impacted other regions progressively. US regions were not impacted.
The failures were caused by an authorization claim change in a core networking dependency, which led to codespace pool provisioning failures. Alerts detected the issue but did not have the appropriate severity, leading to delayed detection and response. Learning from this, we have improved our validation of changes to this backend service and monitoring during rollout. Our alerting thresholds have also been updated to catch issues before they impact customers and improved our automated failover mechanisms to cover this area.
February 12 10:38 UTC (lasting 34 minutes)
On February 12, 2026, from 09:16 to 11:01 UTC, users attempting to download repository archives (tar.gz/zip) that include Git LFS objects received errors. Standard repository archives without LFS objects were not affected. On average, the archive download error rate was 0.0042% and peaked at 0.0339% of requests to the service. This was caused by the deployment of an incorrect network configuration in the LFS Service that caused service health checks to fail and an internal service to be incorrectly marked as unreachable.
We mitigated the incident by manually applying the corrected network setting. Additional checks for corruption and auto-rollback detection were added to prevent this type of configuration issue.
Follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog.
The post GitHub availability report: February 2026 appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み