GitHubの過去の稼働時間

 (damrnelson.github.io)
1 ポイント 投稿者 GN⁺ 2026-04-01 | 1件のコメント | WhatsAppで共有
  • 2016年から2026年までのGitHubの月別稼働時間を可視化したページ
    • すべてのデータは公式ステータスページで収集された記録に基づく
  • 平均稼働率(Average) と 詳細な停止内訳(Breakdown) を分けて見られる構成
  • ページ内から元データソース(View source) に直接アクセス可能
  • 長期的なサービス安定性の推移をひと目で確認できる可視化資料
  • 別途の分析や解説なしにデータ可視化中心で構成された形式

関連記事

1件のコメント

 
GN⁺ 2026-04-01
Hacker Newsの意見

  • 2018年以前のデータが本当に正確なのか気になった
    昔も何度も障害があった記憶がある
    おそらくその時点から現在のuptime追跡システムを使い始めたのかもしれない

    • データは公式のstatusページから取られている
      ただ、このページは監視用というよりマーケティング/コミュニケーション用に近かった気がする

  • 個人的にはこの代替ステータスページのほうが良いと思う
    「The Missing GitHub Status Page」という名前で、直近90日間の可用性比率を総合的に見せている
    現在は90.84%で、数日前の90.00%より少し改善している

    • 最近の状況はかなり荒れていた
      GitHub Actionsの2026年2月の可用率は98%で、シングルナイン相当だ
      体感では50回に1〜2回（約2%）くらい失敗していた気がする
    • こういう総合値はあまり合理的な指標ではない気がする
      たとえばOpenAIが落ちてCoPilotが動かないとき、それをGitHubのダウンタイムと見なしていいのかという疑問がある
    • 実際には両方のページは同じ統計を違う見せ方で表示しているだけだ
      OPはMicrosoft買収後の結果を強調したい形で示しているように思える
    • 「90%だとほぼ5週間のダウンタイム」という計算になる
      冗談ではあるが、GitHubももうそれだけの『有給休暇』を取る資格ができたということだ

  • 機能が導入された時点を表示せずにデータを見せるのは偏っている
    たとえばGitHub Actionsは2019年8月にリリースされたのだから、それ以前にダウンタイムがないのは当然だ

    • 「Breakdown」で「Actions」をクリックするとその項目を隠せる
    • 詳細ページを見ると個別サービスの振れ幅は小さくなるが、全体的な傾向は同じように見える
    • さらに悪いのは、存在していなかった時期まで「100% uptime」と表示される点だ

  • 自分も数週間前にClaudeで同じグラフを作ってみた
    Microsoft買収の前後で急激な低下があると予想していたが、実際にはずっと前から不規則な障害パターンが続いていた
    買収前のほうが安定していたという物語は興味深いが、当時はActionsのような製品がなかった
    存在していたサービス（API、Git ops、Pagesなど）はむしろ可観測性の改善で説明できそうだ

    • Actionsのリリース後、運用と可用性の面で悪夢のような状況が始まった印象がある
      その後、問題はIssuesやPRのような安定していた領域にも広がった
    • 個人的にはGitHub Actions自体がなくなるべきだと思う
      Gitはもともと一つのことをうまくやるよう設計されたツールなのに、そこへ不要な機能を継ぎ足したのが大きな失敗だった

  • みんなが理由を探しているなら、このThe New Stackの記事が説明になるかもしれない

    • 完全に同意する。うちのチームでのAzure障害とGitHub障害はほぼ同時に起きる
      もはや一種のミームになっている
    • ただ、6年以上続いている低い可用性をこの理由一つで説明するのは難しいと思う
      テストを別環境で十分に行い、短期間でAzureへ移行すべきだった

  • 現在PRマージ機能が動いていない
    関連ステータスはGitHub Status Incidentページで確認できる

  • 昔はユニコーンのエラーページをよく見た記憶がある
    おそらく当時はステータスページが頻繁に更新されていなかった

    • ユニコーンはWebページ専用のエラーだった気がする
      Git APIのようなサービスは別に壊れることもあり、ステータスページには時間差で反映されることがよくあった

  • 今ではGitHubのダウンタイム記録が自分の個人サーバーより悪い気がする
    自分は実験のためによく再起動したりサービスを止めたりしているのにだ

    • それでも私たちはまだ金を払っている
      品質低下があってもQoS水準は保たれると信じているようだ
    • 自分の小さなVPSですらGitHubより測定可能なレベルで安定している

  • 自分はGitHubを擁護する側ではないが、そのグラフは軸が歪められている
    99.5%以下の区間だけ拡大しているので、実際よりはるかに悪く見える

    • でも0から描いたら良いサービスと悪いサービスの差が見えない
      企業向けSLAは99.9%なのに、グラフの下端はそれより5倍多いダウンタイムを示している
      つまり悪く見えるのではなく、実際に悪いのだ
    • グラフには**負荷（load）**の要素が反映されていない
      Microsoft買収前は個人リポジトリが1つに制限されていたことも考慮すべきだ
    • uptimeチャートを0から描く必要はない
      99%台の範囲だけを見せるのは合理的だ
      対数スケールはむしろやりすぎだと思う

  • GitHub PagesでWebサイトを配信しているので、静的ホスティングの可用性を別途調べてみた
    このブログ分析によると、GH Pagesはこの分野ではかなり良い成績を出している
    ただし、その功績はFastly CDNに帰すべきだろう