ハクソク

世界を動かす技術を、日本語で。

GitHubに問題が発生しています

83日前原文(githubstatus.com)

概要

  • 2026年3月3日に発生したGitHubのサービス障害の時系列まとめ
  • 影響を受けた主なサービス：Git Operations、Webhooks、API Requestsなど
  • 障害発生から復旧までの対応状況
  • 各サービスの復旧状況と運用再開の報告
  • 詳細な原因分析（Root Cause Analysis）は後日共有予定

GitHubサービス障害発生と対応状況

  • 2026年3月3日18:59（UTC）より Actions、Copilot、Issues の可用性低下を検知
  • 19:00以降、 API Requests、Pull Requests、Webhooks など複数サービスで性能低下・可用性低下を確認
    • 19:03、 GitHub全体でサービス劣化 を認識し、影響範囲を調査開始
  • 19:05～19:36、 Webhooks、Pull Requests、Codespaces、Issues、Git Operations で断続的な性能低下や可用性低下
  • 19:17、 原因を特定し、緩和策を適用。一部サービスで回復傾向を確認
  • 19:23以降、 Issues、Webhooks、Pull Requests、Codespaces、API Requests の順に正常運用へ復帰
  • 19:33、 複数サービスで回復 を確認。主な影響はGit Operationsへ限定
  • 19:36～19:54、 Git Operations の劣化継続も、19:54に正常運用へ復帰
  • 19:55～20:06、 Actionsを含む全サービスの復旧 を確認し、監視を継続
  • 20:09、 インシデントの完全解決 を報告。ユーザーへの感謝と今後の詳細分析（Root Cause Analysis）共有予定を通知

影響を受けたサービス一覧

  • Git Operations ：リポジトリ操作
  • Webhooks ：外部連携通知
  • API Requests ：API経由のリクエスト
  • Issues ：課題管理
  • Pull Requests ：プルリクエスト管理
  • Actions ：CI/CD自動化
  • Codespaces ：クラウド開発環境
  • Copilot ：AIコーディング支援

今後の対応

  • 詳細な原因分析（Root Cause Analysis） の公開予定
  • ユーザーへの継続的な情報提供と再発防止策の徹底

Hackerたちの意見

Codebergはgit CLIだとちょっと遅いかもしれないけど、少なくとも毎週「URLがエラー: 500を返しました」って状況にはなってないからマシだよね…。

└

CodebergのURLがちゃんと読み込めることってほとんどないんだよね。悲しいことに、実際におすすめしたいんだけど、信頼性がないからなぁ。そうは言っても、GitHubは今やマイクロソフトだし、あのMicrosoft 365の稼働率で有名だからね。

└

これってCodebergの問題じゃなくて、CopilotとActionsの問題だから、「URLがエラー: 500を返しました」って状況じゃないよね。

└

いや、スケールの違いは分かるよね？

└

最近は、VPSに裸のリポジトリを置いてsshで使うってことをみんな忘れちゃったみたいだね。

└

2年前にコードバーグを使ってたんだ。ちょっと時代を先取りしすぎたかも。

これ、絶対私のせいだわ。インフラ作業を何週間もやらないこともあるし。GitHubは問題なく動いてるし、ステータスページも全部緑だしね。でも、デプロイフローを調整したり、テストインフラを更新したりする日が来ると、タスクの途中で全てがダウンしちゃうんだよね。障害が起きると、最初に「何してるの？」って聞かれるのが私になってるし、これが結構な頻度で起こるんだよ…。

└

パウリ効果って知ってる？

└

プロットツイスト：cpfohlはGitHubで働いていて、実際にインフラをいじってるんだ。

└

これからはインフラ作業をする時は、事前に教えてくれると助かるよ。

└

あなたはSRE（シュレーディンガー信頼性エンジニア）に昇進すべきだよ。

└

これでネット上での信頼度がめっちゃ上がるだろうね。

└

シンプルな解決策：数週間ごとじゃなくて、数ヶ月ごとにインフラ作業をやるべきだよ。

└

うちの父親みたいだな。エレベーターに閉じ込められるのが得意だったんだよね。しかも、閉所恐怖症のセラピストと一緒に閉じ込められたこともあった。

これ、Cloudflareに関係してるのかな？OpenAI APIリクエストでcf-mitigated: challengeが出てるんだけど。 https://www.cloudflarestatus.com/ https://status.openai.com/

こういう障害が面白いのは、今やGitHubに依存してるものがgitホスティングだけじゃないってことだよね。CIパイプライン、パッケージレジストリ、リリース自動化、デプロイトリガー、Webhook — たくさんのインフラが静かにGitHubが常に利用可能だと仮定してる。GitHubが不調になると、ビルドやリリースのチェーン全体が壊れちゃうから、影響範囲が意外と大きいんだよね。

└

多くのインフラが、GitHubが常に利用可能だと静かに前提にしてるのが本当に不思議だよね。サービスが完全にダウンしていなくても、週に一回は何かしらの問題があるのに。ここ2ヶ月でHNに載ってる障害が20件近くあるよ: https://news.ycombinator.com/from?site=githubstatus.com 「常に利用可能」って言葉はどうなっちゃったんだろう。

マイクロソフトが関わると、何でも台無しになるね。

こんな時には、CIツールに「緊急モード」を用意しておくと便利だよね。プロダクションのCIインフラがダウンしてる時に、ゼロからプロダクションのCIパイプラインを走らせる方法が必要なんだ。そうじゃないと、CIのダウンタイムが他のプロダクションのダウンタイムと重なった時に、プラットフォームが「ブリック」状態になっちゃうこともある。実際に見たことがあるけど、全然楽しくないよ。緊急モードを設定するのは面倒だけど、特にレガシーなCIのゴミが多いとね。でも、障害が発生した時にはその効果が大きいんだ。私たち（dagger.io）は、この緊急モードの設定を簡単にするツールを提供してるから、CIロジックをCIインフラから切り離してるんだ。でも、どんなツールを使っても関係ないよ。ローカルマシンからブートストラップCIパイプラインを実行できるようにしておくことが大事。後で感謝されると思うよ。

└

100%。私たちは、パイプラインをローカルで簡単に再現できるように設計してたよ。例えば、CIランタイムのプラグインに依存しないようにね。build.shのシェルスクリプトを考えてみて。通常はCIランナーによって呼び出されるけど、ローカルでも簡単に実行できるんだ。

└

ちょっと前、ポッドキャストでその痛点について話してるのを聞いた気がする。自分も経験したことがあるし、すごく魅力的な解決策に聞こえた。1、2年前のダガーのドキュメントはAIばっかりだったのを覚えてるけど、正直それが嫌で離れたんだ。でも、今はそれがなくなったみたいだね。CIに戻る感じなの？

└

クリティカルなワークロードを扱うシステムには必須だね。Fastlyでは、インターネットのトラフィックのかなりの部分を処理していて、プロダクションの障害が起きた時にCIシステムが復旧するのを待ってる間に「ダウン」するわけにはいかない。私たちは、GH Actionsの上にdagger.ioを使ってCIプラットフォームを構築したんだけど、「ブレイクグラス」パターンは後付けじゃなくて、最初からの要件だったんだ（それがプラットフォームの基盤としてdaggerを選んだ主な理由の一つでもある）。

└

それを提案すると、いつもみんなの反応が微妙で、結局独自の方法で進めることが多いんだ。だから、緊急時の解決策はペアプログラミングを推奨してる。

└

こういう時、プロダクション環境へのデプロイに関わってない自分がすごく嬉しい。私たちは、（徹底的に検証した後に）顧客が自分のエアギャップネットワークにインストールできるソフトウェアをリリースしてるから。USBメモリを使ってエアギャップを越える感じ。もしリリースが1日か3日遅れても、顧客に届く前のプロセスには余裕があるから、誰も気づかないし。2026年にはクレイジーだけど、インストール可能なソフトウェアには開発者にも顧客にもメリットがあるんだよね。もっといろんなことをこういうやり方でやれたらいいな。

GitHubに問題がない時に投稿してくれると、ノイズが減っていいな。

└

そうそう。私のクライアントの中でGitHubをGitForgeとして使ってるのは一人だけで、他はみんな自分たちのGitForgeをホストしてる。どれだけ他のGitForgeが優れているかは言葉にできないよ。数年前はGitHubがGitForgeの頂点だったのに、今は壁にぶつかりたがってるみたい。そうじゃなきゃ、こんなにソフトウェアをクソにする理由は説明できないよ。

SSH経由のディレクトリがあなたのGitサーバーになり得るよ。CIがそんなに複雑じゃなければ、Dockerにループするpost-receiveフックで十分かも。数週間前に自己ホスティングのGitとビルドについて書いたよ[1]。もっと重いソリューションもあるけど、こういうのをバックストップとして設定するのも役立つかもしれない。もしあなたのブログがChatGPTのトラフィックで大変なことになってるなら、GitHubのことも考えてあげて。彼らのトラフィックがすごいことになってるのは想像に難くないよ。 1: https://duggan.ie/posts/self-hosting-git-and-builds-without-...

└

ポストリリーブってプッシュ操作をブロックして、プッシュをキャンセルするとキャンセルされるんじゃなかったっけ？

└

gitリポジトリのオリジンは、リモートの.gitディレクトリの内容に過ぎない。それだけ。SSHを使って輸送するのが満足なら、gitサーバーを立てる必要もないよ。そうだね。自分の.git/を「ベア」gitリポジトリにすることは確かにした方がいいけど、それが基本だし。私もそうしてるよ：プライベートGitリポジトリにアクセスできるOCIコンテナを使ってる（U2FでSSHを設定して、Yubikeyを使っていろんなマシンからそのGitリポジトリにプッシュ/プルできる）。

みんなが言う「gitはハブなんて必要ない」ってやつね。要するに、分散型だからどこかに「ホスティング」する必要がないんだよね。誰かのマシンのリポジトリからでもプッシュやプルができるし。GitHubはオンラインバックアップとして扱えばいいんじゃない？ダウンしてるからって開発が止まる理由はゼロだし。

└

問題は、CIやPR、コードレビュー、デプロイなどの自動コード変更プロセスが中央のgitサーバーに依存してるってことだよね。セキュリティもGHに同期されたSSOロールに基づいて特定のリポジトリへのアクセスを許可してるかもしれないし。セルフホストのgitサーバーは簡単だけど、それを基にしたものがフォールバックできるようにするのは簡単じゃない。特にGHは多くの統合がすぐに使えるからね。

昔は主にGitlabが問題を抱えてたのを思い出す。GitHubはめっちゃ安定してたのに、フロントエンドをサーバーレンダリングのページからReactに切り替えたら、クソになっちゃった。それから最近のCo-pilotの話も、Railsモノリスについて自慢してるのは聞かないな。

└

今でも自分に問いかけるのは、なんで彼らがReactに切り替え始めたのかってこと。全然意味がわからなかった。ちゃんと動いてる製品なのに、なんで切り替えるの？新しい開発者がReactに慣れてるのはわかるけど、トレードオフが明らかになった時点で、俺ならすぐにやめてたよ。でも彼らは「みんな、準備して！製品を台無しにしよう！」って言ってたんだよね。