ハクソク

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

GitHubがダウンしています

概要

GitHubの複数サービスで発生したパフォーマンス低下と障害の時系列まとめ。
影響範囲、復旧状況、監視体制、今後の対応方針を整理。
最終的に全サービスが正常化し、詳細な根本原因分析は後日共有予定。
利用者への感謝と協力要請も明記。
障害発生から解消までの流れを簡潔に記載。

GitHubサービス障害の発生と復旧状況

  • 2026年5月4日15:45 UTC頃IssuesWebhooksにてパフォーマンス低下が発生
  • 15:48 UTCGit Operationsや他の複数サービスでレイテンシ増加タイムアウトを確認
  • 15:50〜16:06 UTC、以下のサービスでパフォーマンス低下可用性低下が順次発生
    • Git Operations
    • Packages
    • Actions
    • Pull Requests
    • Codespaces
    • Pages
  • 各サービスの障害状況を随時アップデートし、調査と復旧作業を継続
  • 16:25 UTC以降、各サービスが順次正常化を確認
    • Git OperationsActionsPackagesPagesPull RequestsIssuesCodespacesWebhooksの順で復旧
  • 16:29 UTC全体的なレイテンシ正常化を確認
  • 16:36 UTC障害の緩和を完了し、安定性監視を継続
  • 16:40 UTCすべての障害が解消したことを発表

今後の対応と利用者へのメッセージ

  • **根本原因分析(Root Cause Analysis)**を後日共有予定
  • 障害発生時の利用者の協力と理解に感謝
  • 再発防止策の検討と継続的な監視体制の強化方針
  • 障害発生時は迅速な情報提供透明性の確保を重視

Hackerたちの意見

今のところ、「GHがダウンしてる」って投稿が「最新のLLMハイプ」と競い合ってるね。個人的なプロジェクトのために、すべてをCodebergに移そうかなって考えてる。GHの安定性も理由の一つだけど、大手テック企業に縛られない代替案っていうのもいいなと思ってる。
あなたの名前がGitHubの稼働時間のクソみたいな状況を要約してるね。
でも、まだ改善されてないよね。それが支配的なプラットフォームの問題なんだよ。ちょっとした不便さと慣れがあれば、誰も動かないからね(独占的な悪用がなくても – ここではMicrosoftのことを言ってる)。
2027年: 「GitHubが復活!」
「可用性の三つの8」
これ、パフォーマンスが許容できないレベルに達してるよ。GHで仕事が中断されない週なんてない。
もう許容範囲を超えてると思う。
数ヶ月間許容できなかったけど、今は「積極的に代替案を探すべき」ってレベルになってる。
AIエージェントのおかげで、インターネット全体のスケーラビリティが変わったんだ。以前は、GitHubは限られた人数の人間がリアルな方法でプラットフォームとやり取りするのに頼っていたから、そういうパターンに合わせてスケールして、UIやUXのホットスポットを最適化していたんだろうけど、今はみんなが24時間稼働するモルトボットを持っていて、時には複数動かしているから、かなりのサービスがオーバーロードしてる。特に、今やエージェント中心になっているGitHubみたいなサービスはね。
ヨーロッパでは状況がずっと良いよ。私はこの事件が始まる数時間前に仕事を終えたから、ここ数ヶ月の間に大きな作業停止の事件を思い出せない。最近影響を受けたのは、夕方に趣味のことをしようとした時だけだね。
一週間?事故がない日が一日以上続くなんて、嬉しいことだよ。今、何回目の月曜日の朝PSTか分からなくなっちゃった。
面白いことに、Copilot以外はほぼ全てが劣化してるみたい。時々、ジョークが自分で書かれるよね。
Copilotのフル機能は、現在劣化しているものに比べたらほんの少ししか役に立たないよ。
GitHubは驚くべき使用率の増加を発表したけど、それはエージェンティックコーディングの普及によるものだって。いつかはレート制限を変更したり、無料プランの使用を制限したり、負荷を減らすための別の方法を見つける必要があるだろうね。彼らのインフラはこの大幅な増加に追いつけてないのが明らかだし、増加したコストを自分たちで吸収するなんてあり得ないと思う。GitHubの未来がどうなるのか、すごく気になる。
彼らは自分たちがその状況を作り出し、続けていることを考えると、問題として引用することはできないよね。
個人的には、もう後戻りできないところまで来てると思う。彼らが自分たちが掘った穴から水平スケールで抜け出すのは難しいんじゃないかな。無料と有料のインフラを分ける必要があるかもしれないけど、他のインフラの変更を見てるとそれも難しそうだし。製品を切り替えるには10倍良くなる必要があるのと同じように、10倍悪くなったら競合はただじっとしてるだけで10倍の恩恵を受けることになるからね。
GitHubを通るデータって、Microsoftがコストを負担してもいいくらい価値があるんじゃないの?その価値をどうやって捕らえるのかはっきりしないけど、90%は誰でもスクレイピングできるAI生成コード(公開プロジェクト)か、使えない(プライベートプロジェクト)ものになるから、あなたの言う通りかもしれないね。
何十年も見てきたけど、操作が安価なシステムと、スケールアウトするために頑張ってるシステムがあるんだよね。前者は後者を圧倒的に上回ることが多い。例えばGitHubは、メインリポジトリ/プルページを検索クエリとして実装してるみたいで、事前に入力された検索バーがそれを示唆してるし、先週検索バックエンドがダウンしてプルリクが読み込まれなかったことでほぼ確認できた。でも、オープンプルリクを読み込むだけのシンプルなAPIコールとして実装できたはずで、そのAPIは存在していてダウンしてなかった。もしGitHubが、ページ読み込みやそれに伴うAPIコールなどの上位95%の操作を特定して効率化に力を入れたら、バックエンドの負荷を5倍以上減らせると思うよ。(差分ビューアについては、話が長くなるからやめておくけど、フロントエンドがすごく非効率的なのは分かってるし、バックエンドを直接読み込まないのも問題だと思う。改善の余地はたくさんあるはず。普通のgitコマンドラインの機能はすごく速いし。)
4月3日のGitHub COOからの情報:プラットフォームの活動が急増中。2025年には10億のコミットがあった。今は週に2.75億で、成長が線形のままなら今年は140億に達するペース(ネタバレ:そんなことはないけど)。GitHub Actionsは2023年の週500M分から2025年には1B分、今週はすでに2.1B分に増えてる。だから、もっとCPUを増やして、サービスをスケールさせて、GitHubのコア機能を強化するためにすごく頑張ってるんだ。https://x.com/kdaigle/status/2040164759836778878 それに、最近の可用性についてのブログ記事もあったよ: https://github.blog/news-insights/company-news/an-update-on-... GitHubのエンジニアたちが直面しているスケーリングの問題は、全然羨ましくないな! #HugOps
同じ会社がXboxネットワークも運営してる。もっと多くのアクティブユーザーと、もっと多くのイベントが毎秒発生してる。
LinkedInのサーバー容量を全部GitHubに再配分するべきだって、ずっと主張してるよ。
コパイロットをみんなに売り込もうとしてるから、その数字を盲目的に信じるのはちょっと難しいよね。確かにAIが彼らの作業量を増やしてるのは間違いないけど、示されてる数字のどれだけが本当で、どれだけがPR部門がコパイロットやその仲間たちを大成功に見せようとしてるのか、わからないよ。
へぇ、バイブコーディングが最近GitHubがダウンしてる理由なんだ!
マイクロソフトが何年もAIを押し進めてきたのに、これを予測できなかったのは驚きだね。
GitHubは過去90日間で84.92%の稼働率だって、https://mrshu.github.io/github-statuses によると。これがどうして許容範囲に近いのか全く理解できないよ。
どこかに少なくとも一つの9がある…
そうじゃないよ。最近は受け入れられないことがたくさん起きてるのに、みんなそれを普通に受け入れてるみたい。
個人的には、そのサイトはダウンタイムを過大評価してると思う。主要な障害や重大な障害(HNのトップページに載るようなやつ)だけをフィルターにかけると、状況はまだ悪いけど、84.92%ほどひどくはないよ。 https://isgithubcooked.com/?severities=major.critical
二つの8も取れないのに、三つの9なんて無理だね。
そこに9があるから、大丈夫だよ!
GitHubがサービス障害を起こすタイミングがなんとなく分かるようになってきたのが、ちょっと変な感じ(悲しい?)。さっき、プルリクエストで「会話を解決」ってクリックしたら、エラーメッセージが出て、何回か失敗したんだ。ページの下の方に表示されてて、最初の数回は気づかなかったし。新しいアクションをサーバーに認識させるために、毎回ページをリロードしなきゃいけなかった。同僚にも話したんだけど、「GitHubが他のサービスで問題を抱えてるかもね、それがプルリクのコメントにも影響してるのかも?これが大きな障害に繋がるかも?」って言ったよ。
まさに今、プルリクのレビューコメントで同じ信号を感じた。ステータスページをチェックしたら、緑だったから「長くは続かないだろうな」って思ったよ。
ほんとにバカバカしいよ。人によっては「欠落してる」ステータスページを無視するけど、コパイロットを含んでることを考えると、プルリクエスト(95.5%)の方がコパイロット(96.4%)よりも可用性が低いってことも注目すべきだよね。PRにアクセスできないのに「LGTM」ってコメントしろってどういうこと?
「GitHubはダウンしていない」っていうページも必要だと思う。もちろん、他のダウンしてる時のためにね。
10:01 PTの時点で、インシデントを削除してステータスページを全部グリーンにしたってこと???