Die bisherige Verfügbarkeit von GitHub

• Eine Seite, die die monatliche Verfügbarkeit von GitHub von 2016 bis 2026 visualisiert
  • Alle Daten basieren auf gesammelten Einträgen der offiziellen Statusseite
• Die Darstellung trennt durchschnittliche Verfügbarkeit (Average) und detaillierte Ausfallübersicht (Breakdown)
• Innerhalb der Seite ist ein direkter Zugriff auf die ursprüngliche Datenquelle (View source) möglich
• Visualisierungsmaterial, mit dem sich langfristige Trends der Service-Stabilität auf einen Blick erfassen lassen
• Ohne zusätzliche Analyse oder Erläuterung, klar auf Datenvisualisierung fokussiert

[GN⁺]

Hacker-News-Kommentare

• Ich habe mich gefragt, ob die Daten von vor 2018 tatsächlich korrekt sind.
  Ich erinnere mich, dass es auch früher schon mehrere Ausfälle gab.
  Vielleicht wurde ab diesem Zeitpunkt erst das heutige Uptime-Tracking-System verwendet.

  • Die Daten stammen von der offiziellen Status-Seite.
    Diese wirkte allerdings eher wie ein Werkzeug für Marketing/Kommunikation als für Beobachtbarkeit.

• Persönlich finde ich diese alternative Status-Seite besser.
  Sie heißt „The Missing GitHub Status Page“ und zeigt die Verfügbarkeitsrate der letzten 90 Tage in aggregierter Form.
  Aktuell liegt sie bei 90,84 %, also etwas besser als die 90,00 % von vor ein paar Tagen.

  • Die Lage war zuletzt ziemlich rau.
    GitHub Actions hatte im Februar 2026 eine Verfügbarkeit von 98 %, also nur auf dem Niveau einer einzelnen „9“.
    Gefühlt schlug etwa 1–2 von 50 Malen fehl, also ungefähr 2 %.
  • Solche aggregierten Kennzahlen scheinen kein besonders sinnvoller Maßstab zu sein.
    Wenn zum Beispiel OpenAI ausfällt und CoPilot dadurch nicht funktioniert, ist fraglich, ob man das als GitHub-Downtime zählen sollte.
  • Tatsächlich zeigen die beiden Seiten nur dieselben Statistiken auf unterschiedliche Weise.
    Es wirkt, als wolle der OP die Ergebnisse seit der Microsoft-Übernahme besonders hervorheben.
  • Bei „90 %“ kommt man rechnerisch auf fast 5 Wochen Downtime.
    Als Witz formuliert: GitHub hat sich damit inzwischen wohl so viel „bezahlten Urlaub“ verdient.

• Es ist verzerrend, Daten zu zeigen, ohne den Einführungszeitpunkt der Funktionen zu markieren.
  GitHub Actions wurde zum Beispiel erst im August 2019 veröffentlicht, daher ist es nur natürlich, dass es davor keine Ausfälle gab.

  • Unter „Breakdown“ kann man „Actions“ anklicken, um diesen Eintrag auszublenden.
  • Auf der Detailseite schrumpft der Umfang der einzelnen Dienste, aber der Gesamttrend bleibt gleich.
  • Noch schlimmer ist, dass sogar Zeiträume, in denen der Dienst gar nicht existierte, als „100 % Uptime“ angezeigt werden.

• Ich habe vor ein paar Wochen mit Claude ebenfalls denselben Graphen erstellt.
  Ich hatte erwartet, vor und nach der Microsoft-Übernahme einen steilen Einbruch zu sehen, aber tatsächlich gab es schon lange vorher ein unregelmäßiges Ausfallmuster.
  Die Erzählung, dass es vor der Übernahme stabiler gewesen sei, ist interessant, aber damals gab es Produkte wie Actions noch nicht.
  Bei den bereits existierenden Diensten (API, Git ops, Pages usw.) könnte es eher durch verbesserte Beobachtbarkeit erklärbar sein.

  • Seit der Einführung von Actions fühlt sich der Betrieb in Sachen Verfügbarkeit wie ein Albtraum an.
    Danach griffen die Probleme auch auf zuvor stabile Bereiche wie Issues oder PRs über.
  • Ich persönlich finde, GitHub Actions sollte verschwinden.
    Git wurde ursprünglich als Werkzeug entworfen, das eine Sache gut macht, und es war ein großer Fehler, darauf unnötige Funktionen draufzupacken.

• Falls Leute nach einem Grund suchen: Dieser Artikel von The New Stack könnte eine Erklärung liefern.

  • Stimme ich vollkommen zu. Die Azure-Ausfälle unseres Teams und GitHub-Ausfälle treten fast gleichzeitig auf.
    Inzwischen ist das schon fast ein Meme.
  • Trotzdem lässt sich die seit mehr als 6 Jahren anhaltende geringe Verfügbarkeit meiner Meinung nach nicht allein damit erklären.
    Man hätte in einer getrennten Umgebung gründlich testen und innerhalb kurzer Zeit nach Azure migrieren müssen.

• Aktuell funktioniert die PR-Merge-Funktion nicht.
  Den zugehörigen Status kann man auf der GitHub-Status-Incident-Seite sehen.

• Ich erinnere mich, dass ich früher oft die Unicorn-Fehlerseite gesehen habe.
  Damals wurde die Status-Seite vermutlich nicht besonders häufig aktualisiert.

  • Das Unicorn war wohl ein Fehler, der nur die Website betraf.
    Dienste wie die Git API fielen separat aus, und auf der Status-Seite wurde das oft mit Verzögerung sichtbar.

• Inzwischen wirkt GitHubs Downtime-Historie schlechter als die meines privaten Servers.
  Dabei starte ich oft neu oder stoppe Dienste für Experimente.

  • Trotzdem zahlen wir weiter.
    Offenbar glauben wir, dass trotz Qualitätsverlust noch ein gewisses QoS-Niveau gehalten wird.
  • Sogar mein kleiner VPS ist messbar stabiler als GitHub.

• Ich bin niemand, der GitHub verteidigt, aber der Graph hat eine verzerrte Achse.
  Es wird nur der Bereich unter 99,5 % vergrößert gezeigt, wodurch es viel schlimmer aussieht, als es tatsächlich ist.

  • Wenn man aber bei 0 anfängt, sieht man den Unterschied zwischen guten und schlechten Diensten nicht.
    Die Enterprise-SLA liegt bei 99,9 %, und der untere Bereich des Graphen zeigt fünfmal so viel Downtime.
    Es sieht also nicht nur schlecht aus, es ist tatsächlich schlecht.
  • Der Graph berücksichtigt keinen Load-Faktor.
    Man sollte auch bedenken, dass es vor der Microsoft-Übernahme eine Beschränkung auf ein einziges privates Repository gab.
  • Ein Uptime-Diagramm muss nicht bei 0 beginnen.
    Es ist sinnvoll, nur den Bereich im 99-%-Segment zu zeigen.
    Eine logarithmische Skala wäre eher übertrieben.

• Ich nutze GitHub Pages zum Hosten einer Website und habe daher die Verfügbarkeit von statischem Hosting separat untersucht.
  Laut dieser Blog-Analyse schneidet GH Pages in diesem Bereich ziemlich gut ab.
  Der Verdienst dafür dürfte allerdings eher dem Fastly-CDN gebühren.