GitHub wirkt trotz aufrechterhaltener 99,9% Verfügbarkeit überfordert

• In letzter Zeit häufen sich Dienststörungen bei GitHub, sodass es offenbar nicht nur am branchenüblichen „5 nines“ (99,999 %) mangelt, sondern selbst „3 nines“ (99,9 %) schwer zu erreichen sind
• Am 9. Februar kam es bei wichtigen Funktionen wie Actions, Pull Request, Benachrichtigungen und Copilot gleichzeitig zu Störungen, und einige Dienste waren mehrere Stunden lang verzögert
• Aufgrund eines Problems bei der Verteilung von Copilot-Richtlinien kam es bei einigen Nutzern bis zum Vormittag des 10. Februar zu Fehlern bei der Modellanzeige
• Nachdem GitHub die Struktur seiner Statusseite geändert hat, ist die Verfügbarkeitsverfolgung über die letzten 90 Tage erschwert, und in inoffiziellen Daten sind sogar Zeitpunkte mit weniger als 90 % Verfügbarkeit zu erkennen
• Obwohl das Enterprise Cloud SLA eine Verfügbarkeit von 99,9 % festschreibt, ist diese tatsächlich nicht für alle Nutzer garantiert, wodurch der Bedarf an Betriebsstrategien für den Umgang mit Ausfällen wächst

---

Sinkende Verfügbarkeit und häufige Dienststörungen bei GitHub

• Während häufige Ausfälle von Cloud-Diensten zunehmend zum Normalfall werden, kämpft auch GitHub mit Stabilitätsproblemen
  • Es fällt bereits die Formulierung, dass es „kaum einen Tag ohne Störung“ gebe; nicht einmal „5 nines“ (99,999 %), sondern sogar „1 nine“ (90 %) seien schwer zu erreichen
• Am 9. Februar (UTC) waren mit Actions, Pull Request, Benachrichtigungen und Copilot alle wichtigen GitHub-Funktionen von Störungen betroffen
  • GitHub teilte gegen 15:54 Uhr mit, dass es „Probleme bei einigen Diensten“ gebe, und erklärte, dass sich Benachrichtigungen um etwa 50 Minuten verzögerten
  • Um 17:57 Uhr war die Verzögerung auf etwa 30 Minuten gesunken; um 19:29 Uhr wurde die Wiederherstellung gemeldet
• Die Copilot-bezogene Störung dauerte länger an
  • Von 9. Februar 16:29 Uhr bis 10. Februar 9:57 Uhr trat bei einigen Nutzern ein Problem bei der Verteilung von Copilot-Richtlinien auf
  • Dadurch wurden neu aktivierte Modelle den Nutzern teils nicht angezeigt
• GitHub hat die Struktur seiner Statusseite geändert, wodurch die Nachverfolgung der Verfügbarkeit über die letzten 90 Tage erschwert wird
  • Zwar werden Details bereitgestellt, doch die Form wurde so geändert, dass sich der allgemeine Uptime-Trend visuell nur schwer erfassen lässt
  • Daten der inoffiziellen Wiederherstellungsseite (mrshu.github.io/github-statuses/) zeigen, dass die Verfügbarkeit im Jahr 2025 zeitweise unter 90 % gefallen ist
• Das Enterprise Cloud SLA von GitHub nennt 99,9 % Uptime, garantiert diese jedoch nicht allen Nutzern
  • In der Branche gelten „5 nines“ als Idealwert, doch bei einigen Anbietern wird die Realität bereits so bewertet, dass selbst 90 % nur schwer zu halten sind
  • Das deutet darauf hin, dass Kunden Betriebspläne unter der Annahme von Ausfällen vorbereiten müssen

Relevanter Kontext und Beispiele

• GitHub war zuletzt wegen KI-Funktionen und Richtlinienänderungen mehrfach in der Kritik
  • Prüfung eines „Kill Switch“ für KI-Code in Pull Requests

  • Rücknahme geplanter Tarife für selbst gehostete Runner

    • Es gibt den Fall, dass das Zig-Sprachprojekt GitHub wegen der KI-zentrierten Politik von Microsoft verlassen hat
    • Zusammen mit diesen Vorfällen trägt die abnehmende Dienststabilität dazu bei, den Unmut in der Entwickler-Community zu verstärken

Fazit

• Die jüngsten Störungen bei GitHub machen ein Verfügbarkeitsproblem sichtbar, bei dem selbst „drei Neunen“ (99,9 %) schwer zu erreichen sind
• Da die Instabilität zentraler Funktionen wie Copilot anhält, rückt die Sicherstellung der Zuverlässigkeit Cloud-basierter Entwicklungsplattformen als wichtige Aufgabe in den Vordergrund
• Die Notwendigkeit einer Strategie für den Umgang mit Ausfallzeiten wird erneut unterstrichen

[elbanic]

GitHub ist ein kostenloser Dienst; schon die Erwartung von Hochverfügbarkeit an sich ist...

[cosine20]

Ob Sie dann wohl auch dasselbe sagen würden, wenn KakaoTalk eine Störung hat …

[malkeu]

Sieht so aus, als würde git reset --hard helfen.

[master6559]

Wenn es bei GitHub nur keine Ausfälle gäbe, wäre es so, wie es jetzt ist, eigentlich gut.

[GN⁺]

Hacker-News-Meinungen

• Das Uptime-Problem von GitHub ist eindeutig ernst, aber nur weil nicht alle Funktionen gleichzeitig verfügbar waren, zu sagen, „GitHub insgesamt ist down“, halte ich für übertrieben
  Ich nutze Copilot fast nie, daher ist es mir egal, wenn dieser Dienst häufig ausfällt
  Wirklich wichtig ist die Stabilität der Kernfunktionen wie Git, Website, API und Actions

  • Stimme zu. Aber in den letzten 90 Tagen hat kein einzelner Dienst eine **3x9-(99,9-%-)**Uptime erreicht
    Laut dem Enterprise SLA von GitHub müssen pro Dienst mindestens 99,9 % garantiert werden; die tatsächlichen Werte kann man hier sehen
  • Die Formulierung „GitHub ist down“ ist zwar übertrieben, aber selbst die API kommt real nur auf 99,69 %, also gerade einmal zwei Neunen
    Copilot liegt auf dem Niveau von einer Neun, und für die Kerndienste Git und Actions gilt dasselbe
  • Dieses Unternehmen gehört zum Portfolio eines globalen Konzerns im Wert von 1 Billion US-Dollar
    Dass ein Unternehmen mit solchen Ressourcen seine Kunden hängen lässt, ist durch nichts zu entschuldigen
  • Das, was große Unternehmen heute als „5 nines“ bezeichnen, ist fast eine Illusion
    In der Praxis werden sogar Fehlerantworten oft noch als „normaler Betrieb“ gezählt
    Echte 99,999 % wie in der Netzwerkbranche sind selten, und meistens hält man die Statusseite nur mit Data-Slicing-Tricks grün

• Seit der GitHub-CTO 2025 angekündigt hat, durch eine „vollständige Migration zu Azure“ die Zuverlässigkeit zu erhöhen, habe ich ein ungutes Gefühl
  Früher rief die Community noch „fügt schneller neue Features hinzu“, aber heute sind Stabilität und Zuverlässigkeit viel dringender

  • Trotzdem ist GitHub beim Hinzufügen neuer Features immer noch langsam
  • Wenn man nicht nur große Plattformen nutzt, gibt es auch kleine Alternativen, die langweilig stabil sind
  • Ich bin damals in dieser Zeit dazugestoßen, und schon die Möglichkeit, mein Repo öffentlich zu teilen, fand ich faszinierend
  • Insgesamt hat sich die Stabilität in der Branche verbessert, aber heute hängen unzählige Abhängigkeiten zusammen, sodass schon ein Problem an einer Stelle das Ganze erschüttert
  • Ich hoffe fast schon, dass sie bei der vollständigen Umstellung auf Azure den IPv6-Zugang nicht wieder vergessen

• GitHub leidet derzeit unter einer Dreifachbelastung aus Azure-Migration, KI-basierten Infrastrukturänderungen und explodierendem KI-Traffic
  Bei beliebten Projekten treffen oft schon wenige Minuten nach dem Anlegen eines Issues Dutzende KI-erzeugte PRs ein
  Solche Lasten sind schwer zu bewältigen, und die „N 9s“ vor KI und die „N 9s“ nach KI sind Anforderungen von völlig unterschiedlichem Schwierigkeitsgrad

  • Genau. GitHub wurde ursprünglich nicht für ein Umfeld mit außer Kontrolle geratenen KI-Agenten entworfen

• Ein Blick auf die Statusseite von GitHub zeigt effektiv nur 90,21 %, also eher das Niveau von einer Neun
  Im früheren Archiv von 2019 gab es pro Monat 1 bis 4 Ausfälle; heute ist es eher einer pro Tag

  • Dass diese Zahl so schlecht aussieht, liegt nicht nur an reiner Downtime, sondern auch daran, dass degraded performance mit einfließt
  • Im Scherz hieß es aber auch, besser als status.claude.com sei es immer noch

• Während GitHub zwanghaft an KI-Funktionen arbeitet, bricht die Sicherheit der Plattform auseinander
  Kürzlich wurde Aqua Security angegriffen und mehrere Repos wurden infiziert; dabei wurde die mutable-reference-Schwachstelle in GitHub Actions ausgenutzt
  GitHub kennt dieses Problem, hat es aber nicht behoben

  • Als Behelf sollte man Actions-Versionen auf einen Hash pinnen
    Beispiel: uses: actions/checkout@11bd7190...
    Für Automatisierungstools siehe mheap/pin-github-action
  • Ich finde, CI/CD ist durch die YAML-basierte Komplexität völlig verheddert worden
    Früher hat man mit Jenkins deployt und einfache Tests per Skript erledigt, heute ist alles zu einer verteilten YAML-Hölle geworden
  • Die Sicherheit von GHA ist so schlimm, dass Formulierungen fallen wie „mehr Löcher als Schweizer Käse“
  • Es gibt auch Community-Diskussionen, in denen solche Probleme seit Jahren liegen gelassen werden

• 90 % Uptime ist ein Wert über alle Dienste hinweg, daher kann sich die tatsächliche Nutzungserfahrung anders anfühlen
  Aber selbst Copilot mit 96,47 % schafft nur das Niveau von einer Neun
  GitHub empfiehlt, „alle Funktionen gemeinsam zu nutzen“, aber je mehr man das tut, desto schneller sinkt die Zuverlässigkeit drastisch

  • Außerdem tauchen Fälle von „langsam, aber funktioniert noch“ in der Statistik nicht auf
    Zum Beispiel kann schon das Öffnen eines einfachen PR-Diffs über 30 Sekunden dauern
  • Manche Störungen werden offiziell auch erst verspätet gemeldet
    Es gab Fälle, in denen CI/CD, Git und die PR-Funktionen gleichzeitig ausgefallen sind
  • Im Vergleich zu den Daten von 2019 hat sich die Lage heute um mehr als das Zehnfache verschlechtert
  • 96 % ist wirklich ein katastrophaler Wert

• Aus Sicht von jemandem, der GitHub Enterprise Server selbst betrieben hat, überraschen mich diese Probleme nicht
  Grundlegende Anforderungen an Hochverfügbarkeit werden nicht erfüllt, etwa kein Active-Active-Support, keine Upgrades ohne Downtime und kein Rollback
  Wenn ein Bug auftritt, bleibt außer dem Wiederherstellen eines Backups nichts übrig, und dabei kommt es zu Datenverlust
  Ein solches Produkt an hochpreisige Kunden zu verkaufen, ist ein Beleg für Gleichgültigkeit gegenüber Verfügbarkeit

  • Unser Unternehmen hat GHES am Ende ebenfalls aufgegeben und ist zu GHEC migriert

• Microsoft hat ein Talent dafür, gute Produkte kaputtzumachen
  Skype ist das Paradebeispiel, und bei Windows, Notepad und Explorer ist es nicht anders
  Auch das Branding-Chaos von Office → Office 365 → Microsoft 365 → Copilot 365 ist gravierend

  • Der Tag von „GitHub for Business“ ist vermutlich auch nicht mehr fern

• Unser Unternehmen führt für jeden PR Sicherheitsscans mit GitHub Actions aus
  Wenn GitHub ausfällt, stehen auch die Security Gates still, und Entwickler mergen ohne Prüfung
  So gelangt verwundbarer Code ins System, während GitHub sein Personal nur in Copilot steckt

  • Manche fragten auch, ob es dafür öffentliche Beispiele gibt

• Das Ignorieren von IPv6 steht sinnbildlich für GitHubs technische Nachlässigkeit
  Das größere Problem ist, warum man in diesem Zustand überhaupt noch Security Audits besteht
  Ein Blick in GitHubs Sicherheitsdokumentation zeigt, dass sie kaum über Formalitäten hinausgeht

  • Auch die Qualität der Audits ist genauso miserabel wie die Architektur selbst