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

本日もGitHub Actionsがダウンしています

2026年5月26日原文(githubstatus.com)

概要

  • 2026年5月12日、 13:41~17:43 UTC にサービス遅延が発生
  • Code Scanning、通知、 Slack連携 で処理遅延
  • 原因は 内部データベース移行によるレプリケーション遅延
  • ワーカー増強で復旧対応、全サービス正常化
  • 今後の再発防止策として 専用ワーカープール の構築を計画

2026年5月12日のサービス遅延・復旧報告

  • 13:41~17:43 UTC の時間帯で一部サービスに遅延発生
  • Code Scanning サービスで、53%のチェック実行が15分以上かかる遅延
  • 通知配信の平均遅延 22分
  • Slack連携ウェブフック 配信の平均遅延 20分
  • 遅延の主因は 内部データベース移行作業 による レプリケーションラグ
  • ジョブキューへの高頻度エンキューに対し ワーカー不足 が発生
  • ワーカー増強 による負荷分散で影響を緩和
  • 全サービスが 正常な処理時間 へ復旧
  • 今後の対策として、 高負荷共有キュー用の専用ワーカープール 構築を進行中

タイムライン別状況報告

  • 17:43 UTC :全サービス完全復旧
  • 17:43 UTC :CodeQLサービス復旧完了
  • 16:59 UTC :Webhooks復旧完了
  • 16:29 UTC :Webhooks正常稼働を確認
  • 16:28 UTC :遅延の主因が キューイングサービス と判明、スケールアウト対応で回復傾向
  • 16:18 UTC :Webhooksのパフォーマンス低下継続、調査進行中
  • 15:44 UTC :CodeQLアクションワークフローの問題調査継続、通知・Webhooks・Slack連携でも遅延確認
  • 15:42 UTC :CodeQLアクションが遅延、処理が保留またはタイムアウトによる失敗発生
  • 15:13 UTC :CodeQLのパフォーマンス低下報告を調査開始
  • 14:38 UTC :初期調査開始

今後の対策・改善案

  • 内部データベース移行時のレプリケーション監視強化
  • 高負荷キュー用の専用ワーカープール 設置によるリソース分離
  • ジョブエンキュー増加時の 動的スケーリング 体制の強化
  • サービス復旧プロセスの 自動化・迅速化 推進
  • 関連通知・連携サービスの 遅延モニタリング強化

Hackerたちの意見

今回は俺のせいじゃない!まだ仕事始めてないし。

でも、考えたよね?

請求書を送ろうとしてたところだったよ。今回はおあずけだね。/s

あら、まずいね。それって、少なくとも君みたいな人が他にもいるってことだよね。

その気持ちわかる。最近PCにUbuntuをインストールしたんだけど、ちょうどDDOS攻撃を受けた日だったみたいで、aptリポジトリにアクセスできなかった。他にやることがあったから、次の週まで放置してたんだけど、再開したら途中でSnapcraftがダウンしちゃった。

次は「GitHubでSREやってる」って言うんじゃない?

俺のせいじゃないって!数週間前にみんながパニックになって、Ghostbox CLIを投稿したらアクションがダウンするって思い込んでたんだ。これは開発用のランナーを素早く設定して立ち上げるツールなんだけど、そのスレッドはめちゃくちゃだった。みんな誤解してて、パニックになってどんどん話が大きくなっていった。で、実際に https://ghost.charity が何かを投稿したら、コメント欄の人たちは完全におかしくなって、間違ってたことを受け入れられなかったんだよね。彼らは「GHアクションをダウンさせる」って信じ続けて、Ghostがアクションの無料分を転売してるとか、アクションにDDoS攻撃してるとか思い込んでた。でも実際は、自分のワークフローを設定して、ハイブリッドエージェント/人間の開発作業をクリーンで速くするためのものだったんだ。パニックになったコメント者たちはGitHub/MSを救ってるつもりで、リポジトリを何度も通報して、GitHubが自動で無効にしちゃったみたい。で、GitHub/Microsoftはまだ実際に見てないみたいで、今も自動で無効のまま。GitHubで働いてる人いる?アクションがダウンするのは俺のせいじゃないよ。HNの人たちがGhostが悪いって確信してたけど、実際は良いものなんだ!エージェント的な未来を受け入れよう!

やばい、長時間のGitHubのダウンに備えて緊急プラン考えなきゃ。安全にデプロイできないから。年に何千ドルも払ってるサービスなのに、自分たちでランナーをホストしてるのに…

同じく。せめてGitHubがホストしてるランナーと自分たちでホストしてるランナーを分けてくれれば、自己ホストのランナーがダウンしてもジョブを送れるのに。

年に何千ドルかによるけど、GitLabを自己ホストする方が安くて信頼性が高いかも。組織構造的にも良いし(アクセスや秘密の継承ができる)、個人的にはGitLab-CIの方がGitHub Actionsより良いと思う。JavaScript/NPMスタイルの依存地獄に押し込まれないし。自己ホストも結構簡単で、オムニバスパッケージで全てを扱う単一マシンから、フルスケールのオートスケーリングKubernetesデプロイメントまで選択肢があるよ。

同じこと思ってるよ。私たちはアクションを使って本番環境にデプロイしてるんだけど、イメージをビルドしてECSにプッシュして、デプロイをトリガーするんだ。ここで止まるわけにはいかないよね。なんかこれに落ち着いたのはバカみたいだけど、長い間GitHubは信頼できてたのに、最近は調子が悪くなってきてる。

これは制御の痛みだよ。

Hacker Newsで議論の続きを見る