GitHub可用性レポート：2026年3月
GitHubは2026年3月に発生した4件のサービス障害について報告し、ユーザー設定キャッシュのバグとRedisロードバランサーの設定誤りが原因で、github.comやAPI、GitHub Actions、GitHub Copilotなどに影響が出たと説明し、監視強化やアーキテクチャ改善などの対策を実施中と述べた。
キーポイント
3月3日の大規模障害
ユーザー設定キャッシュのバグによりgithub.comのリクエスト失敗率が約40%、GitHub APIが約43%、GitHub Copilotが約21%に達し、2月の障害と同じ根本原因だった。
3月5日のGitHub Actions障害
Redisインフラ更新時のロードバランサー設定誤りにより、95%のワークフロー実行が5分以内に開始できず、10%がインフラエラーで失敗した。
根本原因と対策
キャッシュメカニズムのキルスイッチ追加と専用ホストへの移行、Redis設定変更の自動化改善など、即時対策と長期的なアーキテクチャ改善を実施中。
影響範囲の詳細
Git操作（HTTP）は約6%のエラー率、SSHは影響なし、GitHub Actionsは1%未満の影響と、サービスごとに影響度が異なった。
影響分析・編集コメントを表示
影響分析
この報告書は、GitHubのような大規模開発プラットフォームにおけるシステム障害の根本原因分析と透明性のある報告の重要性を示している。特にGitHub CopilotやGitHub ActionsなどAI関連サービスへの影響は、AI開発ワークフローの依存度の高さを浮き彫りにし、クラウドサービスの信頼性向上が開発者体験に直結することを再認識させる。
編集コメント
大規模プラットフォームの障害報告は、単なる事実通知ではなく、信頼構築と改善へのコミットメントを示す重要なコミュニケーション。AI開発ツールの依存度が高まる中、サービスの安定性は競争力の核心要素となっている。
タイトル: GitHub可用性レポート: 2026年3月
3月、GitHubサービスの広範囲でパフォーマンス低下を引き起こした4件のインシデントが発生しました。
2026年3月3日 18:59 UTC（継続時間: 1時間10分）
2026年3月3日 18:46から20:09 UTCの間、GitHubはgithub.com、GitHub API、GitHub Actions、Git操作、GitHub Copilot、およびその他の依存サービスに影響を及ぼす可用性低下を経験しました。インシデントのピーク時、github.comのリクエスト失敗率は約40％に達しました。同時刻、GitHub APIリクエストの約43％が失敗しました。HTTP経由のGit操作のエラー率は約6％でしたが、SSHは影響を受けませんでした。GitHub Copilotリクエストのエラー率は約21％でした。GitHub Actionsへの影響は1％未満でした。
このインシデントは、2月初旬に発生したインシデントと根本原因を同じくするもので、ユーザー設定のキャッシュメカニズムへの大量の書き込みが確認されました。この書き込み負荷を軽減する変更をデプロイ中、バグにより全ユーザーのキャッシュが一斉に失効、再計算、再書き込みされる事態が発生しました。負荷の増大はレプリケーション遅延を引き起こし、それが全ての影響を受けたサービスに連鎖しました。我々は、不具合のあるデプロイを直ちにロールバックすることでこの問題を軽減しました。
これらのインシデントが開発者のワークフローを妨げたことを認識しています。GitHubの構築と運用において回復性を高めるための実質的かつ長期的な投資を継続していますが、まだ取り組むべき課題があると受け止めています。目標達成には、既に進行中の抜本的なアーキテクチャ見直しと、緊急的で重点的な改善の両方が必要です。以下の即時対策を実施しています：
- ユーザーへの影響が生じる前に通知を受け、迅速に対応できるよう、キャッシュメカニズムにキルスイッチを追加し、監視を強化しました。
- キャッシュメカニズムを専用ホストに移行しており、将来の問題がこのメカニズムに依存するサービスのみに影響することを保証します。
2026年3月5日 16:35 UTC（継続時間: 2時間55分）
2026年3月5日 16:24から19:30 UTCの間、GitHub Actionsのパフォーマンスが低下しました。この間、ワークフロー実行の95％が5分以内に開始できず、平均遅延は30分でした。また、ワークフロー実行の10％がインフラストラクチャエラーにより失敗しました。これは、回復性向上のために本番環境へ展開中だったRedisインフラストラクチャの更新が原因でした。この更新により、Redisロードバランサーに誤った設定変更が導入され、内部トラフィックが誤ったホストに転送され、2件のインシデントが発生しました。
誤設定されたロードバランサーを修正することで、このインシデントを軽減しました。Actionsジョブは17:24 UTCから正常に実行を開始しました。インシデントをクローズするまでの残り時間は、キューに滞留したジョブの消化に費やされました。
寄与因子となった更新を直ちにロールバックし、フォローアップ作業が完了するまでこの領域の全変更を凍結しました。誤った設定変更がインフラ全体に伝播しないよう、自動化プロセスの改善に取り組んでいます。また、インシデントに発展する前に誤設定されたロードバランサーを検知するため、アラート機能の強化も進めています。加えて、Actions内のRedisクライアント設定を更新し、短時間のキャッシュ中断に対する回復性を高めています。
2026年3月19日 13:44 UTC（継続時間: 48分）
2026年3月19日 01:05から02:52 UTC、および2026年3月20日 00:42から01:58 UTCの間、Copilot Coding Agentサービスのパフォーマンスが低下し、ユーザーは新規Copilot Agentセッションを開始したり、既存セッションを表示したりできなくなりました。最初のインシデントでは、平均エラー率は約53％、サービスへのリクエスト失敗率はピーク時約93％に達しました。2回目のインシデントでは、平均エラー率は約99％、ピーク時は約100％に達し、再試行の増幅も顕著でした。両インシデントとも、サービスがその基盤となるデータストアに接続するのを妨げた、同一の根本的なシステム認証問題が原因でした。
影響を受けた認証情報をローテーションすることで各インシデントを軽減し、接続性を回復させてエラー率を正常値に戻しました。軽減までの時間は1時間24分でした。2回目の発生は、1回目の問題対応が不完全だったことに起因します。
認証情報ライフサイクルイベントの自動監視を実装し、今後この種の問題を検知・軽減するまでの時間を短縮するため、運用プロセスの改善を進めています。
2026年3月24日 16:59 UTC（継続時間: 2時間52分）
2026年3月24日 15:57から19:51 UTCの間、Microsoft Teams統合およびTeams Copilot統合サービスのパフォーマンスが低下し、GitHubイベント通知をMicrosoft Teamsに配信できませんでした。平均エラー率は37.4％、サービスへのリクエスト失敗率はピーク時90.1％に達し、この期間中、全統合インストールの約19％がGitHubからTeamsへの通知を受信できませんでした。
これは、上流依存サービスの一つで発生した障害が原因であり、当該Teams統合に対してHTTP 500エラーと接続リセットを引き起こしました。
関連するサービスチームと連携し、上流のインシデントが軽減された19:51 UTCに問題は解決しました。
今後、同種の問題の軽減までの時間を短縮するため、可観測性と運用手順書の更新に取り組んでいます。
ステータス変更のリアルタイム更新やインシデント後の概要については、ステータスページをご覧ください。現在の取り組みについて詳しくは、GitHubブログのエンジニアリングセクションをご確認ください。
投稿「GitHub可用性レポート: 2026年3月」はThe GitHub Blogに最初に掲載されました。
原文を表示
In March, we experienced four incidents that resulted in degraded performance across GitHub services.
March 03 18:59 UTC (lasting 1 hour and 10 minutes)
On March 3, 2026, between 18:46 and 20:09 UTC, GitHub experienced a period of degraded availability impacting github.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other dependent services. At the peak of the incident, github.com request failures reached approximately 40%. During the same period, approximately 43% of GitHub API requests failed. Git operations over HTTP had an error rate of approximately 6%, while SSH was not impacted. GitHub Copilot requests had an error rate of approximately 21%. GitHub Actions experienced less than 1% impact.
This incident shared the same underlying cause as an incident in early February, where we saw a large volume of writes to the user settings caching mechanism. While deploying a change to reduce the burden of these writes, a bug caused every user’s cache to expire, get recalculated, and get rewritten. The increased load caused replication delays that cascaded down to all affected services. We mitigated this issue by immediately rolling back the faulty deployment.
We understand these incidents disrupted the workflows of developers. While we have made (and are making) substantial, long-term investments in how GitHub is built and operated to improve resilience, we acknowledge we have more work to do. Getting there requires deep architectural work that is already underway, as well as urgent, targeted improvements. We are taking the following immediate steps:
We have added a killswitch and improved monitoring to the caching mechanism to ensure we are notified before there is user impact and can respond swiftly.
We are moving the cache mechanism to a dedicated host, ensuring that any future issues will solely affect services that rely on it.
March 05 16:35 UTC (lasting 2 hours and 55 minutes)
On March 5, 2026, between 16:24 and 19:30 UTC, GitHub Actions was degraded. During this time, 95% of workflow runs failed to start within 5 minutes with an average delay of 30 minutes, and 10% of workflow runs failed with an infrastructure error. This was due to Redis infrastructure updates that were being rolled out to production to improve our resiliency. These updates introduced a set of incorrect configuration changes into our Redis load balancer, causing internal traffic to be routed to an incorrect host leading to two incidents.
We mitigated this incident by correcting the misconfigured load balancer. Actions jobs were running successfully starting at 17:24 UTC. The remaining time until we closed the incident was spent burning through the queue of jobs.
We immediately rolled back the updates that were a contributing factor and have frozen all changes in this area until we complete follow-up work. We are working to improve our automation to ensure incorrect configuration changes cannot propagate through our infrastructure. We are also working on improved alerting to catch misconfigured load balancers before it becomes an incident. Additionally, we are updating the Redis client configuration in Actions to improve resiliency to brief cache interruptions.
March 19 13:44 UTC (lasting 48 minutes)
On March 19, 2026, between 01:05 and 02:52 UTC, and again on March 20, 2026, between 00:42 and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and peaked at ~93% of requests to the service. During the second incident, the average error rate was ~99% and peaked at ~100% of requests with significant retry amplification. Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its backing datastore.
We mitigated each incident by rotating the affected credentials, which restored connectivity and returned error rates to normal. The mitigation time was 01:24. The second occurrence was due to an incomplete remediation of the first.
We have implemented automated monitoring for credential lifecycle events and are improving operational processes to reduce our time to detection and mitigation of issues like this one in the future.
March 24 16:59 UTC (lasting 2 hours and 52 minutes)
On March 24, 2026, between 15:57 and 19:51 UTC, the Microsoft Teams Integration and Teams Copilot Integration services were degraded and unable to deliver GitHub event notifications to Microsoft Teams. On average, the error rate was 37.4% and peaked at 90.1% of requests to the service—approximately 19% of all integration installs failed to receive GitHub-to-Teams notifications in this time period.
This was due to an outage at one of our upstream dependencies, which caused HTTP 500 errors and connection resets for our Teams integration.
We coordinated with the relevant service teams, and the issue was resolved at 19:51 UTC when the upstream incident was mitigated.
We are working to update observability and runbooks to reduce time to mitigation for issues like this in the future.
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: March 2026 appeared first on The GitHub Blog.
関連記事
リポジトリ内の全プロジェクトの Git 設定を編集可能に
Vercel は、モノレポで多数のプロジェクトを展開するユーザー向けに、各プロジェクトの Git 設定（コミットステータスやリポジトリディスパッチイベントなど）を一括で管理・適用できる機能を追加した。これにより、個別の設定画面へのアクセスが不要となり、効率的な運用が可能になった。
Elastic Build Machines がメモリ不足ビルドから保護へ
Vercel は、ビルドのメモリ使用量を監視し、メモリ不足による失敗を防ぐため自動的にマシンをアップグレードする機能を Elastic Build Machines に導入した。これにより、高速だがメモリ集約的なビルドでもダウングレードされなくなる。
デプロイメント一覧の再設計
Vercel は、より多くのデプロイメントを一度に表示できる高密度レイアウトへデプロイメント一覧を再設計しました。環境がステータスと共にグループ化され、ブランチやコミットの確認が容易になりました。また、モバイル環境での使い勝手も向上しています。