IssuesとWebhooksの障害 – 解決済み

 (githubstatus.com)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • GitHub は Issues と Webhooks のパフォーマンス低下を調査した後、2026年5月4日 16:40 UTC に障害を解決済みへ移行した
  • 今回の障害は Git Operations、Webhooks、Issues、Pull Requests、Actions、Packages、Pages、Codespaces に影響した
  • 15:45 UTC に Issues と Webhooks のパフォーマンス低下の調査が始まり、15:48 UTC には複数の GitHub サービスにおける 遅延増加 と タイムアウト の調査へ拡大した
  • 16:25 UTC から Git Operations、Actions、Packages、Pages、Pull Requests、Issues、Codespaces、Webhooks が順次 正常化 するか緩和された
  • GitHub はサービス全体の レイテンシ が正常化したとし、再発防止と 根本原因分析 を引き続き進め、準備ができ次第共有すると明らかにした

障害概要

  • GitHub は Issues と Webhooks のパフォーマンス低下の報告を調査した後、障害が解決したと告知した
  • 障害は Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces に影響した
  • GitHub は問題対応の間待ってくれたユーザーに感謝を伝え、詳細な 根本原因分析 は準備ができ次第共有すると明らかにした

進行状況

  • 調査開始

    • 2026年5月4日 15:45 UTC に Issues と Webhooks のパフォーマンス低下の報告を調査中だと告知された
    • 15:48 UTC には複数の GitHub サービスで 遅延増加 と タイムアウト を調査中だと拡大告知された

  • 影響サービスの拡大

    • 15:48 UTC に Git Operations がパフォーマンス低下を起こしていると告知された
    • 15:50 UTC に Packages がパフォーマンス低下を起こしていると告知された
    • 15:51 UTC に Actions がパフォーマンス低下を起こしていると告知された
    • 15:51 UTC に Pull Requests が可用性低下を起こしていると告知された
    • 15:56 UTC に Pull Requests がパフォーマンス低下を起こしていると告知された
    • 16:05 UTC に Codespaces がパフォーマンス低下を起こしていると告知された
    • 16:06 UTC に Pages がパフォーマンス低下を起こしていると告知された

  • 正常化と緩和

    • 16:25 UTC に Git Operations が正常動作していると告知された
    • 16:28 UTC に Actions と Packages が正常動作していると告知された
    • 16:29 UTC に Pages が正常動作していると告知された
    • 16:29 UTC にサービス全体の レイテンシ が正常化し、根本原因の調査と再発防止を継続中だと告知された
    • 16:32 UTC に Pull Requests が正常動作していると告知された
    • 16:34 UTC に Issues に影響したパフォーマンス低下が緩和され、安定性確認のため監視中だと告知された
    • 16:35 UTC に Codespaces に影響したパフォーマンス低下が緩和され、安定性確認のため監視中だと告知された
    • 16:35 UTC に Webhooks が正常動作していると告知された

  • 解決

    • 16:36 UTC にパフォーマンス低下が緩和され、安定性確認のため監視中だと告知された
    • 16:40 UTC に障害が 解決済み 状態へ移行した
    • 詳細な 根本原因分析 は提供可能になり次第共有される予定だ

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの反応

  • GitHubはエージェント型コーディングの増加が原因だとして驚くような利用量の増加を公表したが、結局どこかの時点でレート制限を変えるか、無料ティアの使用量を減らすか、負荷を下げる別の方法を見つける必要がありそう
    インフラがこの増加ペースに追いついていないのは明らかで、増えたコストをGitHubがそのまま負担し続ける可能性は低い。今後GitHubがどうなるのか気になる

    • 4月3日にGitHubのCOOがすでにプラットフォーム活動が急増していると明かしていた
      2025年にはコミット数が10億件だったが、現在は週2億7,500万件で、線形増加だけでも今年は140億件ペースだという。GitHub Actionsも2023年の週5億分から2025年には週10億分へ増え、今週はすでに21億分に達した
      CPU追加、サービス拡張、GitHubの中核機能強化を非常に強力に進めているとのこと
      https://x.com/kdaigle/status/2040164759836778878
      可用性に関する最近のブログ記事もある: https://github.blog/news-insights/company-news/an-update-on-...
      GitHubエンジニアが直面しているスケーラビリティ問題は本当に相当厳しそうだ
    • 数十年見てきた感覚では、各処理を安くするシステムと、ひたすら水平スケールするシステムがあり、前者が後者に大きく勝つことが多かった
      たとえばGitHubはリポジトリの/pullsページを検索クエリのように実装しているようで、事前入力された検索ボックスがそのヒントだったし、先週の検索バックエンド障害でプルリクエストが読み込めなくなったことでほぼ確信した。しかし、単に開いているプルリクエストだけを取得する普通のAPI呼び出しでも実装できたはずで、そのAPIは存在し、障害も起きなかった
      GitHubがページ読み込みや、それに付随するAPI呼び出しのような上位95%レベルの処理を見つけて効率化することに集中すれば、単純化だけでもバックエンド負荷を5倍以上減らせそうだ
      diffビューアにも改善の余地が大きそう。ひどい非効率のかなりの部分はバックエンドを直接圧迫していないフロントエンド側だろうが、普通のgitコマンドライン機能は非常に速い
    • もう引き返せない地点に近づいている気がする。無料インフラと有料インフラを分離しない限り、自分で掘った穴から水平スケーリングだけで抜け出せるのか分からない
      誰かに製品を乗り換えさせるには10倍良くなければならないと言うが、既存製品が10倍悪くなれば競合は何もしなくても無料で10倍得をする
    • 1週間前にGitHubがブログでこうした内容を出し、その翌日にGitHub幹部がHNコメントで繰り返したことで、2019年以降続いてきた信頼性低下は2019年のMicrosoft統合のせいではなく、2023年になって初めて現れた何かのせいだという認識が一気に常識のようになった
      PRは効く。GitHubが落ちるのはあまりに成功しすぎたから、という結論になった
    • LinkedInのサーバー容量を全部GitHubに再配置することを強く支持してきた

  • https://mrshu.github.io/github-statusesによると、GitHubの直近90日の稼働率は84.92% らしい
    これがどうして少しでも許容できる水準なのか分からない

    • そのサイトは停止時間を過大計上しているようだ。HNのトップページに載るようなmajorとcriticalの障害だけに絞ってもまだ悪いが、84.92%ほどではない
      https://isgithubcooked.com/?severities=major.critical
    • 許容できるわけがない。最近は許容できないことがたくさん起きているのに、みんな平然と受け入れているように見える
    • three ninesどころかtwo eightsすら満たせていない

  • もう性能は受け入れがたい水準に来ている。GitHubのせいで業務が中断しない週がない

    • AIエージェントが事実上、インターネット全体のスケーラビリティ特性を変えてしまった
      以前ならGitHubは、限られた数の人間が人間らしいやり方と観測可能なパターンでプラットフォームを使うと想定でき、そのパターンに合わせてスケールし、UI/UXのボトルネックを最適化できただろう
      しかし今は誰もが24時間動くボットを1つ、時には複数持っていて、多くのサービスが過負荷になっている。特に最近のGitHubのようにエージェント中心になったサービスではなおさらだ
    • 数か月前からすでに受け入れがたい水準だったし、今は代替を積極的に探すべき段階に近い
    • 1週間どころか、障害なしで1日過ぎるだけでも喜ぶべきレベルだ
      太平洋標準時の月曜朝になるたび、これが何度目なのかもう分からない
    • ヨーロッパではかなりましだ。今回の障害が始まる数時間前に仕事を終えていたし、この数か月で業務を止めるほどの大きな障害はあまり記憶にない
      最近、夜に趣味のプロジェクトをやろうとして影響を受けたことは一度あった
    • 受け入れがたい水準はとっくに通り過ぎていると思う

  • 今やHNトップページではGitHubダウンの投稿が、毎週の新しいLLM誇大宣伝投稿と競い合うレベルになっている
    個人プロジェクトは全部Codebergへ移すことを検討中。GitHubの安定性も理由だが、ビッグテック企業に厳密に縛られていない代替という点も気に入っている

    • Claude Codeがほとんど魔法のようだというスパムがいちばんひどかったが、しばらくGitHubのステータス投稿に押されているようだ。今はClaude広告が静かな時期なのかもしれない
    • それでもまだ移行していないというのが支配的プラットフォームの問題だ。少しの不便と慣性だけで、誰も離れなくするには十分だ
      独占的な濫用がなくてもそうで、ここではMicrosoftのことを言っている

  • 面白いことに、Copilot以外のほぼすべてが性能低下状態に見える。冗談がひとりでにできる状況だ

    • 今性能低下している機能群と比べれば、Copilotの機能全体は有用性の一部でしかない
    • CopilotはGitHubのコードホスティング側とは完全に独立していて、Railsモノリスへの強い依存がない全く別のインフラで動いているのだろう

  • GitHubで障害が起きるときを察知する第六感が身についてきた気がして、妙だし少し悲しい
    1時間ほど前、プルリクエストで「Resolve Conversation」を押したら何度か失敗し、エラーメッセージがページ下部の画面外に出ていて最初は見えなかった。何回か操作するたびに、サーバーが新しい状態を反映するまでページを更新しなければならなかった
    同僚には、GitHubで別のサービスに問題が出ていて、それがPRコメント側に波及したようだ、もっと大きな障害に転がるかもしれないと話していた

    • さっきPRレビューコメントでも同じ兆候を見た。ステータスページを確認したら緑だったが、長くは続かないだろうと思っていたらその通りだった

  • 無料ティアを削るべきだ
    この2.5か月でコミットを4,000件していて、それもmain基準だ。回帰テスト用の成果物も毎日大量に上げている
    コストは0ドルだ

    • 正直、こういうSaaS製品の無料ティアは嫌いだ
      昔、Googleがごく短期間だけGCPで従量課金のGitサービスを提供していたとき、それを使っていた。自分のものを自分で所有したかったからだ。でもみんな「無料」のGitHubを使い、多くの他のGoogleサービスと同様、そのサービスも終了してしまったようだ
      だから今はGitHubを無料で使っているが、むしろ大手クラウド事業者にリポジトリと利用量の費用を払いたい
    • そうすると、まだ離れていないオープンソースプロジェクトが移住するだろう
    • リポジトリ側だけを見れば、それはCPU使用時間2分くらいに近い
    • GitHubは雑コード税を課すべきだ。Claudeとの共同執筆？金を払え。コメントにem dashが多い？金を払え。短時間に大量のコードが書かれた？金を払え

  • 本当にばかげた水準に達しつつある。ステータスページがCopilotまで含めて「落ちた」とたまに無視されることはあるが、プルリクエストの可用性は**95.5%**で、Copilotの96.4%よりも低い点を見るべきだ
    PRにすらアクセスできないのに、どうやって「LGTM」とコメントしろというのか分からない

  • 少なくとも人々はgit remoteコマンドの使い方を覚えつつある