GitHub erneut von einer Störung betroffen

 (githubstatus.com)
1 Punkte von GN⁺ 2026-02-10 | 2 Kommentare | Auf WhatsApp teilen
  • Bei einigen GitHub-Diensten wurde eine verminderte Leistung gemeldet, wodurch es zu Verzögerungen bei der Zustellung von Benachrichtigungen kam
  • Die durchschnittliche Verzögerung stieg zunächst auf etwa 50 Minuten und später auf bis zu 1 Stunde 20 Minuten
  • Anschließend erfolgte schrittweise eine Wiederherstellung, wobei sich die Verzögerung von 1 Stunde → 30 Minuten → 15 Minuten verkürzte
  • Am 9. Februar 2026 um 19:29 UTC wurde das Problem als behoben und der Vorfall abgeschlossen gemeldet
  • GitHub will eine Root Cause Analysis (RCA) zu einem späteren Zeitpunkt veröffentlichen

Überblick über den Vorfall mit verzögerten GitHub-Benachrichtigungen

  • GitHub meldete bei einigen Diensten eine verminderte Leistung
    • In der Anfangsphase wurden Benachrichtigungen nicht ordnungsgemäß zugestellt
    • Die Untersuchung der Ursache des Problems lief noch

Verlauf der Benachrichtigungsverzögerung

  • Im ersten Update wurde eine durchschnittliche Verzögerung von 50 Minuten genannt
    • GitHub teilte mit, dass Maßnahmen zur Entschärfung umgesetzt würden
  • In einem späteren Update verschlechterte sich die Lage auf 1 Stunde 20 Minuten Verzögerung, es wurden jedoch Anzeichen einer Erholung beobachtet
  • Die Wiederherstellung schritt weiter voran, sodass sich die Verzögerung auf 1 Stunde → 30 Minuten → 15 Minuten reduzierte
    • Dabei wurde erklärt, dass der Backlog (aufgelaufene Benachrichtigungen) abgearbeitet werde
  • Schließlich wurde das Problem mit den verzögerten Benachrichtigungen behoben, und die reguläre Zustellung wurde wieder aufgenommen

Abschluss des Vorfalls und Folgemaßnahmen

  • Am 9. Februar 2026 um 19:29 UTC wurde der Vorfall vollständig behoben
  • GitHub dankte den Nutzern für ihre Geduld und ihr Verständnis
  • Die Ergebnisse der Root Cause Analysis (RCA) sollen veröffentlicht werden, sobald sie vorliegen

Nutzerbenachrichtigungen und Abonnementfunktionen

  • Nutzer können Updates zum Vorfall abonnieren, etwa per E-Mail, SMS, Slack oder Webhook
  • Mit einem Abonnement stimmen sie den Datenschutzrichtlinien und Nutzungsbedingungen von GitHub und Atlassian zu
  • Die Website ist durch Google reCAPTCHA geschützt

Zusammenfassung

  • Bei diesem Vorfall handelte es sich um ein Verzögerungsproblem im Benachrichtigungssystem von GitHub, das über etwa vier Stunden schrittweise behoben wurde
  • Der Dienst ist inzwischen wieder im Normalbetrieb, ein zusätzlicher Analysebericht ist angekündigt

Verwandte Beiträge

2 Kommentare

 
joyfui 2026-02-10

Dann lag es also nicht nur an mir, dass GitHub heute früh Fehler ausgespuckt hat.
 
GN⁺ 2026-02-10
Hacker-News-Kommentare

  • GitHub veröffentlicht keine Service-Verfügbarkeitsstatistiken mehr, also habe ich die Daten selbst geparst.
    Für den Gesamtdienst wirkt es aktuell wie ein Niveau von „single 9“.
    Auf der Seite GitHub Statuses kann man das sehen.

    • Das erinnert mich an die frühere GitHub-Statusseite. Damals wurde die tatsächliche Verfügbarkeit transparent gezeigt, und es überrascht nicht, dass sie durch die aktuelle Seite ersetzt wurde, sobald die Wahrheit sichtbar wurde.
      Die Erklärung im archive.org-Link habe ich auch mit Interesse gelesen.
    • Die Formulierung „single 9“ für den Gesamtdienst ist aus Sicht der Berechnung der Verfügbarkeit bedeutungslos.
      Die Werte pro Bereich sind in Ordnung, aber alle Services zu einer einzigen Kennzahl zusammenzufassen, ist sinnlos.
      Die meisten liegen über 99,5 %, nur Copilot scheint eine Ausnahme zu sein.
    • Interessant ist, dass Copilot insgesamt den niedrigsten Wert hat.
      Ich nutze es täglich, habe aber kaum Probleme bemerkt. Vermutlich werden Zeitpunkte der Incident-Erfassung verspätet eingepflegt.
    • Ich verstehe nicht, warum der heutige Ausfall als „minor“ eingestuft wurde.
      Die Web-UI funktionierte fast gar nicht, daher frage ich mich, ob GitHub die Schwere von Incidents zu niedrig angibt.
    • Tolles Projekt. Danke fürs Teilen.

  • Noch vor ein paar Jahren hätte ich nicht gedacht, dass GitHubs Dominanz einmal bedroht sein könnte.
    Aber wenn der Betrieb so instabil bleibt, wird das wohl als klassisches Eigentor der Branche in Erinnerung bleiben.

    • Seit der „existenziellen“ Migration zu Azure im letzten Jahr scheint die Verfügbarkeit um ein bis zwei Stufen gefallen zu sein.
    • Ich schaue mir gerade die Seite „Migrate from GitHub“ in der GitLab-Dokumentation an.
      Wenn sich sogar Issues und Projekte mitnehmen lassen, denke ich ernsthaft über einen Wechsel nach.
    • Ich halte das nicht nur für ein Betriebsproblem, sondern für ein Problem von Architektur und Code-Qualität.
      Wer sich GitHub Enterprise self-hosted ansieht, erkennt, wie komplex das alles ist.
    • Ich habe keine Belege dafür, aber ich vermute, dass die häufigen Ausfälle zuletzt auch ein Nebeneffekt der AI-zentrierten Strategie sein könnten.
    • Ich denke, Microsoft hat die erzwungene Migration zu Azure durchgedrückt und AI-Workloads priorisiert.
      GitHub ist die goldene Gans für Entwicklungsdaten weltweit, und wenn es so instabil wird, ist am Ende das ganze Franchise in Gefahr.
      Windows 11 ist auch nicht gerade überzeugend, und GitHub könnte seine Rolle als Grundlage moderner Entwicklung verlieren.

  • Ich war gerade dabei, einen Security-Bug in Caddy zu bearbeiten, als GitHub ausfiel und ich beim Öffnen des Reports nur noch die Unicorn-Seite sah.
    Ich wollte die zwei Stunden ohne Kind konzentriert nutzen, und jetzt habe ich Sorge, dass sich diese Feedback-Schleife durch den Ausfall bis morgen verzögert.
    Trotzdem bin ich dankbar, weil ich dank GitHub Sponsors meinen Lebensunterhalt bestreiten kann.

    • Ich frage mich, um welchen Security-Bug es geht.
    • Ich würde gern fragen, ob du schon einmal über eine alternative Plattform nachgedacht hast. Aus Sicht von jemandem, der einen eigenen Server betreibt, ist Sicherheit wichtig.

  • Man kann in Echtzeit zusehen, wie GitHub immer weiter zerbricht und explodiert.
    Die Seite GitHub Status History ist schon fast Comedy.

    • Es ist erst der 9. Februar, und es gibt schon 14 Incidents.
      Ironisch, dass selbst die Phase des „Retters“ der AI-Industrie wieder so verläuft.
      Passender Artikel: The-Verge-Link
    • Als Scherz meinte jemand, um diesen Trend umzukehren, müsse man einfach mehr vibe coding machen.
    • Trotzdem ist es gut, dass GitHub das transparent offenlegt.
      Die Ausfälle werden nicht versteckt, man kann also reagieren, und vermutlich folgt bald auch ein Postmortem.
    • Bis die Azure-Migration abgeschlossen ist, dürfte so etwas wohl weiter passieren.
    • Schön wäre eine Jahresvisualisierung wie der Beitragsgraph auf GitHub-Profilen.

  • In diesem Jahr hatte GitHub schon so viele Incidents, dass die Statusseite fast jeden Tag aktualisiert wird.
    Wenn man sich den Statusverlauf ansieht, ist das selbst für einen großen Dienst nicht normal.
    Es gibt schon Witze, dass GitHub Actions jeden Tag gegen 16 Uhr ausfällt.
    Ich wünschte, intern würde man Ursachen und Gegenmaßnahmen offenlegen.

    • Seit dem Auftauchen von Coding-Agenten ist der Betriebstraffic womöglich um das Hundertfache gestiegen.
      GitHub wurde ursprünglich für eine andere Größenordnung entworfen und ist nun plötzlich einer völlig neuen Last ausgesetzt.

  • Auf der Statusseite wurde zuerst nur eine Verzögerung bei Benachrichtigungen angezeigt, in Wirklichkeit erschien beim Zugriff auf PRs aber ständig die Unicorn-Seite.
    Danach tauchte eine eigene Statusmeldung zu PRs auf, und schließlich wurde das Ganze zu einem Problem des Gesamtdienstes ausgeweitet.
    Link zum Incident

    • Ein Eintrag mit „Untersuchung zu verringerter Performance einiger Services“ wurde hinzugefügt.
      Um 16:10 UTC war er noch nicht da, wenige Minuten später schon.
    • Beim Genehmigen eines PR liefert die JSON-API eine HTML-Fehlerseite zurück. Intern scheint alles völlig durcheinander zu sein.
    • Ich sehe auch oft 500er-Fehler. Die Latenz ist ebenfalls stark gestiegen.
      Monitoring-Link
    • Auch beim Zugriff auf Commit-Details erscheint nur die Unicorn-Seite.
    • Selbst die git-Befehle funktionieren nicht.

  • Wir haben in den letzten Wochen die Migration zu Forgejo abgeschlossen.
    Unser Unternehmen will die Abhängigkeit von großen Clouds reduzieren, daher war es für uns nicht akzeptabel, dass bei GitHub-/Azure-Ausfällen gleich kritische Infrastruktur stillsteht.
    Der Umstieg verlief reibungslos, und wir arbeiten bereits an einigen kundenspezifischen Erweiterungen.

    1. Wir bauen einen Firecracker-basierten Runner, damit CI in Forgejo Actions in einer VM-Umgebung läuft.
    2. Wir bereiten einen Vorschlag für eine Funktion für Umgebungsvariablengruppen vor.
      Die Community ist sehr aufgeschlossen, und ich hoffe, dass Forgejo weiter wächst.
      Unternehmenslink, Link zur Vorschlagsdiskussion
    • Wenn ihr in London seid, warum nutzt ihr dann eine .eu-Domain? Ich würde gern wissen, wo eure Server stehen und welchen Hosting-Anbieter ihr nutzt.

  • Die Instabilität von GitHub ist inzwischen nicht mehr hinnehmbar.
    Wenn ich künftig Einfluss auf die Wahl eines Code-Repositorys habe, werde ich dazu raten, GitHub zu meiden.

    • Die Funktionen lassen sich auf anderen Forges durchaus ersetzen.
      Nur GitHubs Auffindbarkeit und soziale Signale (Stars, Forks) bleiben weiterhin attraktiv.
      Praktisch wäre es, eine interne Forge wie GitLab oder Gitea zu nutzen und nur auf GitHub zu spiegeln.
      Ironischerweise hätte ich für GitHub vielleicht einen kostenpflichtigen Plan genutzt, wenn es besser wäre, aber aktuell nutze ich nur die kostenlose Version und gebe mein Geld anderswo aus.

  • In den letzten drei Monaten gab es drei größere Ausfälle.
    Das ist auch im Statusverlauf dokumentiert.

    • Ich frage mich, wer das Team zuletzt verlassen hat. Vielleicht ist ein Träger von Schlüsselwissen weggegangen, oder der Betrieb wurde in eine andere Region verlagert.
    • Unser MVP soll in zwei Wochen starten, und schon wieder gibt es einen Ausfall. Das ist frustrierend. Die Zuverlässigkeit ist einfach zu niedrig.
    • Dazu kam noch der Scherz, ob vielleicht auch das wieder an vibe coding liegt.

  • Die aktuelle Situation wirkt fast so, als hätte AI die Engineers ersetzt.

    • „Ja, sorry. Ich habe deine Datenbank gelöscht.“ war die scherzhafte Antwort darauf.
    • Tatsächlich ist mein Verständnis, dass diese Downtime daher kommt, dass GitHub gerade zu Microsoft Azure migriert.
    • Es ist eine Satire darauf, als würden Tay.ai und Zoe.ai intern miteinander kämpfen und deshalb den Dienst nicht am Laufen halten.