3 Punkte von GN⁺ 2025-11-20 | 1 Kommentare | Auf WhatsApp teilen
  • Am 18. November 2025 (UTC) kam es bei GitHub zu einem Ausfall aller Git-Operationen, wodurch SSH-/HTTP-Clients und der Zugriff auf Raw-Dateien unterbrochen wurden
  • Als Ursache wurde ein abgelaufenes TLS-Zertifikat für die interne Service-zu-Service-Kommunikation festgestellt
  • GitHub ersetzte das abgelaufene Zertifikat und startete die betroffenen Dienste neu, womit die vollständige Wiederherstellung abgeschlossen wurde
  • Anschließend wurden die Warnmeldungen zur Überwachung von Zertifikatsabläufen verstärkt; außerdem läuft die Umstellung auf Automatisierung, um manuell verwaltete Zertifikate zu entfernen
  • Der Ausfall betraf Git Operations und Codespaces von GitHub; nach der Wiederherstellung befanden sich alle Dienste wieder im Normalzustand

Bericht zum Ausfall von Git-Operationen

  • Zwischen 20:30 und 21:34 UTC am 18. November 2025 kam es bei GitHub zu einem Ausfall aller Git-Operationen

    • Betroffen waren sämtliche Interaktionen von SSH- und HTTP-Git-Clients sowie der Zugriff auf Raw-Dateien
    • Auch Produkte, die von Git-Operationen abhängen, waren entsprechend beeinträchtigt
  • Als Ursache wurde ein abgelaufenes TLS-Zertifikat identifiziert, das für die interne Kommunikation zwischen Diensten verwendet wurde

    • GitHub löste das Problem durch den Austausch des Zertifikats und den Neustart der betroffenen Dienste
    • Nach dem Neustart der Dienste erfolgte die vollständige Wiederherstellung
  • Um ähnliche Probleme künftig zu verhindern, hat GitHub das Benachrichtigungssystem für Zertifikatsabläufe verstärkt

    • Für andere Zertifikate in den betreffenden Bereichen laufen ebenfalls Überwachung und Prüfungen der Automatisierung
    • Die Beseitigung verbleibender manuell verwalteter Zertifikate und der Aufbau einer automatisierten Service-zu-Service-Kommunikationsstruktur werden beschleunigt

Verlauf des Ausfalls und Wiederherstellungsphasen

  • 20:39 UTC: Beeinträchtigte Verfügbarkeit bei Git-Operationen und Codespaces gemeldet
  • 20:52 UTC: Ausfälle bei einigen Git-HTTP-Operationen bestätigt
  • 21:11 UTC: Ausfall aller Git-Operationen bestätigt
  • 21:25 UTC: Beeinträchtigte Verfügbarkeit bei Codespaces hält an
  • 21:27 UTC: Ursache identifiziert, Behebung in Arbeit
  • 21:36 UTC: Nach dem Deployment des Fixes beginnt die teilweise Wiederherstellung
  • 21:55 UTC: Alle Dienste normalisiert, Wiederherstellung von Codespaces abgeschlossen
  • 21:56 UTC: Normaler Betrieb der Git-Operationen bestätigt
  • 21:59 UTC: Vorfall abgeschlossen und Bericht veröffentlicht

Betroffene Dienste

  • Git Operations
    • Sämtliche SSH- und HTTP-basierten Git-Operationen
  • Codespaces
    • Vorübergehende Beeinträchtigung der Verfügbarkeit

Folgemaßnahmen

  • Überwachung von Zertifikatsabläufen und Automatisierung ausbauen
    • Einrichtung eines Warnsystems vor dem Ablauf
    • Überprüfung der automatischen Erneuerungsprozesse für alle internen Zertifikate
  • Sicherheits- und Betriebsautomatisierung erweitern
    • Abschaffung manueller Zertifikatsverwaltung
    • Aufbau einer automatisierten Service-zu-Service-Kommunikation nach aktuellen Sicherheitspraktiken

1 Kommentare

 
GN⁺ 2025-11-20
Hacker-News-Kommentare
  • Es ist beunruhigend, dass größere Ausfälle von Softwaresystemen in letzter Zeit so häufig auftreten
    Letztes Jahr gab es nur vier Ausfälle mit Auswirkungen auf die Arbeit, in diesem Quartal ist dies bereits der vierte
    Es fühlt sich an, als würde die Resilienz von Netzwerksoftware zunehmend verschwinden
    Unser Team arbeitet mit einer monolithischen Architektur, hat aber viele Abhängigkeiten wie Redis, S3 und externe Integrationsdienste
    Deshalb haben wir vereinfacht, indem wir Ausfallbedingungen dokumentiert, Test- und Deployment-Automatisierung verstärkt und von der Cloud auf VPS umgestellt haben
    Dadurch wurde das System deutlich stabiler und vorhersehbarer
    Ohne diese langweiligen, aber unverzichtbaren Arbeiten wäre nur die Komplexität gestiegen und das System wäre anfälliger geworden
    Die jüngsten Ausfälle, die wir erlebt haben, betrafen AWS us-east-1, Azure Front Door, Cloudflare und GitHub

    • Letztlich geht es, denke ich, um Geld
      Kunden wollen kein Geld für Resilienz oder redundante Infrastruktur ausgeben
      Seit 2008 habe ich an mehr als zehn Projekten gearbeitet, und meistens war die Haltung: „Überlassen wir es einfach dem Glück“
    • Stimme zu. Kostensenkungen führen am Ende dazu, dass man „vergisst, wie man Systeme baut, die auch bei Ausfällen durchhalten“
    • Etwas provokant gesagt glaube ich, dass auch die zunehmende Nutzung von LLMs zu diesem Phänomen beiträgt
  • Git ist ein verteiltes Versionsverwaltungssystem, also kann man auch ohne GitHub arbeiten
    GitHub ist nur ein praktischer Hub

    • Wenn ein Unternehmen allerdings vollständig von GitHub Actions abhängig ist, ist es in einer Situation wie jetzt komplett blockiert
    • Das ist wie: „Diese Rolltreppe ist vorübergehend eine Treppe. Wir entschuldigen uns für die Unannehmlichkeiten.“
    • Der Kern des Problems ist, dass GitHub ausgefallen ist, nicht git selbst
    • Ohne GitHub verliert man die Funktion als Zusammenarbeits-Hub mit anderen
    • Der Grund, warum wir gerade auf Hacker News sind, ist, dass wir nicht arbeiten können
  • Der Mangel an Zuverlässigkeit bei GitHub wirkt gravierend
    Für Menschen, die von CI/CD abhängen, ist das fatal
    Intern scheint es eher als „Das CI/CD unseres Teams ist kaputt“ wahrgenommen zu werden, statt aus der Perspektive „die halbe Welt steht still“
    Eine solche Silo-Kultur und die Haltung „nicht unser Problem“ führen zu sinkender Zuverlässigkeit
    Dazu kommt, dass Kunden wegen der monopolartigen Stellung kaum eine andere Wahl haben und es hinnehmen müssen
    Das erinnert an die Haltung, die man früher schon bei Verio und Verisign gesehen hat: „Ihr könnt ja sowieso nicht woanders hin“

  • Ich frage mich, ob Cloud-/SaaS-Ausfälle heute wirklich häufiger vorkommen
    Ich weiß nicht, ob nur mehr darüber berichtet wird oder ob die Frequenz tatsächlich gestiegen ist
    Liegt es vielleicht an Budgetkürzungen, Personalabbau, AI-Einführung oder überzogenem Wachstum?

    • Microsoft scheint zu glauben, dass das Problem gelöst ist, wenn GitHub auf Azure umzieht
    • Aus Sicht von jemandem, der es lange nutzt, fühlt sich die Zunahme der Ausfallhäufigkeit definitiv real an
      Früher war es ein- oder zweimal im Jahr, heute fast jeden Monat, zuletzt sogar wöchentlich
    • Jemand sagte beim Cloudflare-Ausfall, dass die „AI-basierte Coding-Kultur“ solche Probleme verschärft
      Kleine AI-Codefragmente könnten dominoartige Ausfälle auslösen
    • Wie etwa im Techrights-Artikel,
      wird angenommen, dass Massenentlassungen die sinkende Zuverlässigkeit beeinflusst haben
    • Wegen FOMO (Angst, etwas zu verpassen) rund um AI werden Projektzeitpläne noch enger,
      sodass die letzten 10 % an Stabilitätsarbeit am Ende ignoriert werden
  • Als Push nicht funktionierte, dachte ich zuerst, das Problem läge bei mir
    Ich habe dann einfach beschlossen, es für heute aufzugeben und es morgen noch einmal zu versuchen

    • Authentifizierung funktionierte, aber Push nicht — das war wirklich eine zum Haare raufen frustrierende Erfahrung
    • Selbst das erneute Hinzufügen des SSH-Schlüssels half nicht. Zuerst kamen nur seltsame Fehler, dann schließlich die Meldung „upstream unhealthy“
    • Ich war auch kurz davor, meine Umgebung von Grund auf neu einzurichten
  • Ich hatte heute ohnehin keine Lust zu arbeiten, und nach Cloudflare ist jetzt auch noch GitHub ausgefallen, also wirkt das wie ein Signal, einfach Pause zu machen

    • Das Problem ist die zentralisierte Technologieabhängigkeit mit Fokus auf die USA
      Wir brauchen mehr technologische Souveränität und Dezentralisierung
  • Von allen Diensten, die ich in den letzten fünf Jahren genutzt habe, war GitHub der instabilste
    Ich frage mich, ob GitLab besser ist. Mein Vertrauen in GitHub ist inzwischen fast bei null

    • Unser Unternehmen self-hostet GitLab, aber der Gitaly-Server fällt oft aus
      Vermutlich wegen der großen Monorepo-Umgebung, aber es gibt definitiv Skalierungsprobleme
    • GitLab hat viele Funktionen, aber die Integration ist holprig und der Reifegrad gering
      Trotzdem ist es ein Vorteil, Repository, CI/CD, Issues und Wiki an einem Ort zu haben
    • Ich nutze sowohl GitHub.com als auch self-hostetes GitLab,
      GitHub ist anfällig für Cloud-Ausfälle, während GitLab häufig abgebrochene automatische Upgrades hat
      Beide haben ihre Vor- und Nachteile
    • Ein Problem bei GitLab ist, dass es langsam und schwergewichtig ist
      Es lädt mehrere MB an JS, sodass Seiten in langsamen Netzwerken fast gar nicht aufgehen
    • On-Premises kann man sich so viel Stabilität sichern, wie man möchte
  • In Notfällen kann man Dateien direkt über die GitHub-Web-UI bearbeiten
    Aber actions/checkout@v4 in GH Actions funktioniert wegen des aktuellen git-Problems derzeit nicht

    • Tatsächlich kann man mit git push/pull zu jedem SSH-fähigen Host arbeiten
    • Auch wir waren gerade mitten in einem Production-Hotfix und wurden blockiert. Ich weiß nicht, was derzeit mit dem Internet los ist
    • Auch CircleCI hat wegen Problemen bei der Erkennung von GitHub-SSH-Schlüsseln fehlgeschlagene git-Operationen
    • Diesmal war GitHub AI überraschend hilfreich, weil es darauf hingewiesen hat, githubstatus.com zu prüfen
    • Ich frage mich, ob man über die GitHub-UI Branches anlegen kann
  • In den letzten zehn Jahren habe ich beim Wechsel zwischen Großunternehmen und Startups ein wiederkehrendes Muster gesehen
    Startup → Anforderungen von Enterprise-Kunden → komplexes Redesign → Idealismus → Profitstreben → aufgeblähtes Produkt → Abgang der Kerningenieure → sinkende Qualität
    Dieser Zyklus wiederholt sich auch bei den großen Cloud-Anbietern wie AWS, Cloudflare und GCP
    Intern werden selbst einzelne Services in kleine Business-Einheiten aufgespalten und nach Profitlogik betrieben
    Am Ende wird sogar die grundlegende Infrastruktur durch Gewinndruck geschwächt
    Der Glaube „AWS oder GCP sind so groß, die werden schon nicht scheitern“ erscheint mir gefährlich

    • Stimme zu. Dass Produkte bei der Anpassung an Enterprise-Kunden komplex und träge werden, ist unvermeidlich
      Aber auch die technischen Schulden und Sicherheitsprobleme früher Startups waren gravierend
      Letztlich ist es nur natürlich, dass in Phasen großen Wachstums die Risse im System sichtbar werden
  • Auf der GitHub-Statusseite steht wieder, dass „einige Nutzer Probleme haben könnten“
    Tatsächlich schlagen aber nicht nur HTTPS, sondern auch alle SSH-Pushes fehl

    • Die Verantwortlichen für die Statusseite scheinen sich nicht von der Formulierung „einige Nutzer“ lösen zu können
      PR-artige Euphemismen zu vermeiden und stattdessen transparent zu informieren, würde das Vertrauen eher stärken
      Außerdem kommen selbst die Updates der Statusseite oft verspätet
    • Ein Freund von mir konnte kurzzeitig pushen, aber bei den meisten endet es weiterhin mit einem fatal-Fehler