GitHubでIssues、ActionsおよびGit操作に関する障害が発生

 (githubstatus.com)
1 ポイント 投稿者 GN⁺ 2026-02-10 | 1件のコメント | WhatsAppで共有
  • GitHubのActions、Issues、Git操作など主要サービスで性能低下およびエラーが報告された
  • 影響範囲はWebhooks、Pull Requests、Packages、Pages、Codespacesなどにも拡大した
  • GitHubは**緩和策（mitigation）**を適用して段階的な復旧を確認し、その後すべてのサービスが正常化した
  • 障害はDependabot、Copilotなど一部サービスにも影響したが、最終的に正常処理状態へ復帰した
  • GitHubは根本原因分析（RCA）を後日公開する予定で、ユーザーに忍耐と協力への感謝を表した

障害概要

  • GitHubはActions、Git Operations、Issuesでの性能低下報告を調査中だと発表
    • 初期段階では応答の遅延およびリクエスト失敗、遅延したActionsジョブが観測された
    • 障害は2026年2月9日 19:01 UTCに初めて報告された

影響を受けたサービス

  • 影響を受けたコンポーネントはGit Operations、Webhooks、Issues、Pull Requests、Actions、Packages、Pages、Codespaces
    • その後DependabotとCopilotでも問題が確認された
    • 各サービスは「degraded performance（性能低下）」状態として表示された

対応と復旧の経緯

  • GitHubは緩和策を適用した後、復旧の兆候を観測したと報告
    • 19:29 UTC以降、段階的な回復が進行した
    • 19:54 UTCには多数のサービスが復旧したものの、一部は引き続き調査中だった
  • 20:08 UTCには「すべてのサービスが正常に処理中」と報告された
    • 20:09 UTCに**障害解決（Resolved）**状態へ移行した

最終状態と後続対応

  • GitHubは、すべてのサービスが正常運用状態に戻ったと明記
    • Actions、Codespaces、Git Operations、Issues、Packages、Pages、Pull Requests、Webhooksはすべて正常化
  • **根本原因分析（Root Cause Analysis）**は準備ができ次第共有される予定
  • ユーザーに忍耐と理解への感謝を表明

要約

  • 今回の障害はGitHubの中核的な開発ワークフロー全体に影響した事案
  • 復旧完了後にRCA公開予定であり、今後は類似障害防止に向けた改善が見込まれる
  • 同日に別の障害も報告されたことから、安定性管理の重要性が改めて浮き彫りになった

関連記事

1件のコメント

 
GN⁺ 2026-02-10
Hacker Newsの意見

  • GitHubの継続的な部分障害のせいで、会社全体を別のベンダーへ移すべきか悩んでいる
    以前は問題なく動いていた機能が今では遅く、Actionsも時間どおりに実行されない
    Copilotは良いが、結局git forgeがまともに動かなければ離れるしかない

    • まったく同感。以前は素晴らしかったのに、今では基本機能すら不安定だ
      単純なPR diffを開くだけでも15秒以上かかり、UIが固まったような状態が繰り返される
      こうした異常な性能低下を当然のものとして受け入れているのが驚きだ
    • 「Copilotを楽しんでいる」という言い方は冗談のように聞こえる
    • 皮肉なことに、Linus Torvaldsは中央集権のない構造のためにgitを設計した
      結局、ローカルでもCIパイプラインを回せることこそがgitの本質だ
      自分はGHを単なる同期用としてしか使っていない
    • 以前はGitHubがpostmortemをよく公開していたが、最近はほとんどない
      昔の記事を見ると、SQL DBのスケーリング限界にぶつかっていた
      OpenAIのPostgres拡張事例に似ているが、GitHubはそれほどうまく対処できていないように見える
    • 「信頼できる製品を期待するのは無理」として、Microsoftの問題だと見る声もある

  • GitHubの頻繁な障害は、むしろデプロイパイプラインの復元力を点検するきっかけになっている
    ほとんどのチームがGitHubに完全依存しているため、障害時にはデプロイが止まる
    そのため次のような代替策を試している

    1. 重要なrepoをGitLabやGiteaへミラーリング
    2. ビルド失敗を防ぐための依存関係キャッシュ
    3. GitHub Actionsなしでも手動デプロイできる**ランブック(runbook)の整備
      公式ステータスページはいつも更新が遅く、今では      「eventually consistent」**な情報としてしか扱っていない

  • GitHubは自動化された開発ワークフローの爆発的増加による負荷を受けているのかもしれない
    個人repoのコミットは爆発的に増えたが、有料転換はほとんどない

    • 問題はMicrosoft買収後すでに始まっていた
      2019年のプライベートrepo無料化で収益化の機会を逃したという見方だ
    • 実際にはAWSからAzureへの移行の最中で、それが障害頻発の原因だ
      さらにダウンタイムに対する責任意識も不足している
    • 結局はスケーリング限界に突き当たっている状況だ
    • AIコード生成によってrepo、コミット、データセットが爆発的に増えている
    • 「AI Agentブームに生き、AI Agent崩壊に死ぬ」と要約する声もある

  • GitLabが代替案だと主張する声がある
    GitHubは今やAI中心戦略にしか注力しておらず、プラットフォーム自体は後回しだ
    Copilotの採用率も低く、企業はClaudeをより多く使っている
    Microsoftが方向転換すれば状況はさらに悪化するだろう

    • Copilotは独自モデルなのかと尋ねる質問も出ている
    • ただしGitLabも完璧ではない
      機能が中途半端な状態でリリースされ、速度も遅い
      オープンコアモデルの利点も今では薄れている
    • GitLabもまたAI中心へ変わっている
      Dev → DevOps → DevSecOps → AI DevSecOpsへと進化してきたが
      各段階で完成度が低く、ライセンスアップグレードが必須で不便だ

  • CI/CDとコードホスティングを一体化する構造そのものが問題だと見る意見もある
    完璧に動いたとしても、結局**ベンダーロックイン(lock-in)**は避けられない
    本来はremoteを変えるだけで済むはずが、今ではPRやwikiなどで絡み合ってしまっている

    • 実際これは失敗ではなく、意図的なロックイン戦略だと考えている
    • オープンソースソリューションのforgejoのように独立したCIシステムを使えば多少はましだという意見もある

  • もはやGitHubの障害は単なるSaaSの問題ではなく、クラウドレベルの障害のように感じられる
    そのため多くのチームがセルフホストのGitLab/Giteaへ移行中だ

    • 2つのスタートアップでGitLabをうまく使った経験がある
      大企業ではセキュリティ上の理由からオンプレミスのGitLab Enterpriseを使っており、
      個人プロジェクトはForgejoで運用している
      Git、イシュー、ボード、Wikiのすべてがうまく動き、scopedラベルも無料だ
    • Giteaのセルフホスティングも悪くない。バックアップ管理さえしっかりすればよい
    • GitLabフルバージョンのセルフホスティングはコストに見合う価値が十分ある
    • GitLabのセルフホスティングには確かに満足している

  • GitHubの複数回の障害記録を可視化したページがある
    mrshu.github.io/github-statusesで確認できる

    • updog.ai/status/githubもDatadogのデータを基にしている
    • ただし更新は止まっているように見える（最後は2月6日）

  • 「GitHubチーム、ゆっくりでいいよ」という冗談めいたコメントもある

  • GitHubを離れたいが、安定したCIとコンテナレジストリが必要だ
    「ただちゃんと動く」ソリューションなら対価を払う意思がある

    • Forgejo + Firecracker VMベースのCIを提供するLithus.euを勧める声がある
      大規模ワークロードに適しているが、初期コストは高い
    • GitLab CIはシンプルでありながら強力だ
      レジストリ権限管理はやや複雑だが、全体の統合はよくできている
    • repoがCIまで担うべきなのか疑問だという意見もある
      Unix哲学のように単一目的のツールへ戻るべきだと考えている
    • nix-ci.comを勧める人もいる
    • CircleCIも依然としてよく動く代替案だ

  • AI導入率と障害頻度の相関をグラフで見たら面白そうだ

    • もちろん他の要因も一緒に作用しているはずだ