Störung bei Issues, Actions und Git-Vorgängen auf GitHub

 (githubstatus.com)
1 Punkte von GN⁺ 2026-02-10 | 1 Kommentare | Auf WhatsApp teilen
  • Bei wichtigen GitHub-Diensten wie Actions, Issues und Git-Vorgängen wurden Leistungseinbußen und Fehler gemeldet
  • Die Auswirkungen weiteten sich auf Webhooks, Pull Requests, Packages, Pages und Codespaces aus
  • GitHub wendete Mitigationsmaßnahmen an, bestätigte eine schrittweise Wiederherstellung, und anschließend wurden alle Dienste normalisiert
  • Die Störung betraf auch einige Dienste wie Dependabot und Copilot, kehrte aber letztlich in den normalen Betriebszustand zurück
  • GitHub will die Root Cause Analysis (RCA) später veröffentlichen und dankte den Nutzern für ihre Geduld und Zusammenarbeit

Überblick über die Störung

  • GitHub gab bekannt, dass Berichte über Leistungseinbußen bei Actions, Git Operations und Issues untersucht werden
    • In der Anfangsphase wurden langsame Antworten und fehlgeschlagene Anfragen sowie verzögerte Actions-Jobs beobachtet
    • Die Störung wurde erstmals am 9. Februar 2026 um 19:01 UTC gemeldet

Betroffene Dienste

  • Betroffen waren die Komponenten Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages und Codespaces
    • Später wurden auch Probleme bei Dependabot und Copilot festgestellt
    • Jeder Dienst war mit dem Status „degraded performance“ gekennzeichnet

Reaktion und Wiederherstellung

  • GitHub berichtete, nach Anwendung von Mitigationsmaßnahmen Anzeichen einer Erholung beobachtet zu haben
    • Nach 19:29 UTC setzte eine schrittweise Erholung ein
    • Um 19:54 UTC waren viele Dienste wiederhergestellt, einige wurden jedoch noch untersucht
  • Um 20:08 UTC wurde gemeldet, dass „alle Dienste normal verarbeitet werden“
    • Um 20:09 UTC wurde der Status auf Resolved gesetzt

Endstatus und weitere Maßnahmen

  • GitHub erklärte, dass alle Dienste in den normalen Betriebszustand zurückgekehrt seien
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests und Webhooks wurden vollständig normalisiert
  • Die Root Cause Analysis soll veröffentlicht werden, sobald sie fertig ist
  • Das Unternehmen bedankte sich bei den Nutzern für ihre Geduld und ihr Verständnis

Zusammenfassung

  • Diese Störung betraf den gesamten zentralen Entwicklungs-Workflow auf GitHub
  • Nach abgeschlossener Wiederherstellung soll die RCA veröffentlicht werden, wobei Verbesserungen zur Vermeidung ähnlicher Störungen zu erwarten sind
  • Da am selben Tag noch eine weitere Störung gemeldet wurde, wird die Bedeutung eines soliden Stabilitätsmanagements besonders deutlich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-10
Hacker-News-Kommentare

  • Wegen der anhaltenden teilweisen Ausfälle bei GitHub wird überlegt, die ganze Firma zu einem anderen Anbieter umzuziehen
    Funktionen, die früher problemlos liefen, sind inzwischen langsam, und auch Actions werden nicht rechtzeitig ausgeführt
    Copilot ist zwar nett, aber wenn die git forge am Ende nicht zuverlässig funktioniert, bleibt nur der Wechsel

    • Stimme voll zu. Früher war es großartig, jetzt sind selbst die Grundfunktionen instabil
      Schon das Öffnen eines einfachen PR-Diffs dauert über 15 Sekunden, und die UI wirkt immer wieder wie eingefroren
      Erstaunlich ist, dass man diese abnormale Leistungsverschlechterung einfach hinzunehmen scheint
    • Die Aussage „Ich mag Copilot“ klingt fast wie ein Witz
    • Ironischerweise hat Linus Torvalds git für eine nicht zentralisierte Struktur entworfen
      Im Kern von git steckt ja gerade, dass man CI-Pipelines auch lokal ausführen kann
      Ich nutze GH nur noch zur Synchronisierung
    • Früher hat GitHub häufig Postmortems veröffentlicht, in letzter Zeit aber fast gar nicht mehr
      In älteren Beiträgen sah man, dass sie an die Skalierungsgrenzen ihrer SQL-Datenbank stießen
      Ähnlich wie beim Postgres-Skalierungsfall von OpenAI, nur dass GitHub damit offenbar nicht so gut umgeht
    • Wer von Microsoft ein „zuverlässiges Produkt“ erwartet, verlangt wohl zu viel

  • Die häufigen GitHub-Ausfälle sind eher zu einem Anlass geworden, die Resilienz der Deployment-Pipeline zu überprüfen
    Die meisten Teams hängen vollständig an GitHub, sodass bei einem Ausfall auch Deployments stillstehen
    Deshalb werden folgende Alternativen ausprobiert

    1. Kritische Repos nach GitLab oder Gitea spiegeln
    2. Dependency-Caching, damit Builds nicht fehlschlagen
    3. Ein Runbook vorbereiten, das manuelle Deployments ohne GitHub Actions ermöglicht
      Die offizielle Statusseite wird immer zu spät aktualisiert und gilt inzwischen nur noch als „eventually consistent“

  • Möglicherweise steht GitHub unter Last durch die explosionsartige Zunahme automatisierter Entwicklungs-Workflows
    Die Commits in privaten Repos sind explodiert, aber zahlende Upgrades gibt es kaum

    • Das Problem begann bereits nach der Übernahme durch Microsoft
      Mit den kostenlosen privaten Repos ab 2019 wurde aus dieser Sicht eine Monetarisierungschance vertan
    • Tatsächlich kommt es wohl wegen der Migration von AWS nach Azure so häufig zu Ausfällen
      Außerdem scheint das Verantwortungsgefühl für Downtime gering zu sein
    • Am Ende stößt man schlicht an Skalierungsgrenzen
    • Durch KI-gestützte Codegenerierung explodieren Repos, Commits und Datensätze zusätzlich
    • Zusammengefasst mit: „Vom Boom der AI Agents leben, am Kollaps der AI Agents sterben“

  • Es wird behauptet, GitLab sei die Alternative
    GitHub konzentriert sich inzwischen nur noch auf eine AI-zentrierte Strategie, während die Plattform selbst vernachlässigt wird
    Die Copilot-Adoption ist niedrig, Unternehmen nutzen häufiger Claude
    Wenn Microsoft den Kurs weiter ändert, wird es noch schlimmer

    • Dabei kam die Frage auf, ob Copilot überhaupt ein eigenes Modell nutzt
    • Aber auch GitLab ist nicht perfekt
      Features werden in halbfertigem Zustand veröffentlicht, und auch die Geschwindigkeit ist langsam
      Die Vorteile des Open-Core-Modells wirken inzwischen verblasst
    • Auch GitLab entwickelt sich in Richtung AI
      Von Dev → DevOps → DevSecOps → AI DevSecOps ging die Entwicklung weiter,
      aber in jeder Phase ließ die Reife zu wünschen übrig, und Lizenz-Upgrades sind zwingend nötig, was lästig ist

  • Das eigentliche Problem sei schon die enge Kopplung von CI/CD und Code-Hosting
    Selbst wenn alles perfekt funktioniert, lässt sich Vendor Lock-in letztlich nicht vermeiden
    Eigentlich sollte ein Wechsel nur bedeuten, das Remote zu ändern, aber inzwischen hängt alles an PRs, Wikis und mehr

    • Tatsächlich sei das kein Versehen, sondern eine bewusst gewollte Lock-in-Strategie
    • Mit unabhängigen CI-Systemen wie der Open-Source-Lösung forgejo sei man etwas besser aufgestellt

  • Inzwischen wirken GitHub-Ausfälle nicht mehr wie ein bloßes SaaS-Problem, sondern wie Ausfälle auf Cloud-Ebene
    Deshalb wechseln viele Teams zu selbst gehostetem GitLab/Gitea

    • In zwei Startups wurde GitLab erfolgreich eingesetzt
      Ein Großunternehmen nutzte aus Sicherheitsgründen on-premises GitLab Enterprise,
      private Projekte laufen auf Forgejo
      Git, Issues, Boards und Wiki funktionieren alle gut, und scoped labels sind kostenlos
    • Auch Self-Hosting mit Gitea ist okay. Man muss nur die Backups sauber verwalten
    • Selbst gehostetes GitLab in der Vollversion ist sein Geld absolut wert
    • Mit selbst gehostetem GitLab ist man definitiv zufrieden

  • Es gibt eine Seite, die die Historie mehrerer GitHub-Ausfälle visualisiert
    Zu sehen unter mrshu.github.io/github-statuses

    • Auch updog.ai/status/github basiert auf Datadog-Daten
    • Allerdings scheint die Aktualisierung gestoppt zu haben (zuletzt am 6. Februar)

  • Es gibt auch einen scherzhaften Kommentar: „GitHub-Team, lasst euch ruhig Zeit“

  • Man würde GitHub gern verlassen, braucht aber eine stabile CI und Container-Registry
    Für eine Lösung, die „einfach funktioniert“, wäre man bereit zu zahlen

    • Empfohlen wird Lithus.eu mit CI auf Basis von Forgejo + Firecracker VM
      Gut geeignet für große Workloads, aber mit hohen Einstiegskosten
    • GitLab CI ist simpel und zugleich leistungsfähig
      Das Berechtigungsmanagement der Registry ist etwas kompliziert, aber die Gesamtintegration ist gut
    • Es wird infrage gestellt, ob ein Repo überhaupt für CI zuständig sein sollte
      Man sollte eher zur Unix-Philosophie mit Werkzeugen für jeweils einen Zweck zurückkehren
    • Manche empfehlen auch nix-ci.com
    • CircleCI ist ebenfalls weiterhin eine gut funktionierende Alternative

  • Ein Diagramm zur Korrelation zwischen AI-Einführungsrate und Ausfallhäufigkeit wäre interessant

    • Wobei natürlich auch andere Faktoren eine Rolle spielen dürften