Update zur Verfügbarkeit von GitHub
(github.blog)- Nach den zwei jüngsten Ausfällen richtet GitHub seinen Fokus auf Verfügbarkeit als höchste Priorität und überarbeitet Infrastruktur und Architektur angesichts stark gestiegener Entwicklungs-Workloads und agentic development workflows
- Schon ein einzelner Pull Request ist breit verknüpft – mit Git-Repositories, Actions, Suche, Benachrichtigungen, Berechtigungen, Webhooks, APIs, Hintergrundjobs, Caches und Datenbanken –, sodass kleine Ineffizienzen im großen Maßstab zu Warteschlangenstaus und Weitergabe über Abhängigkeiten führen können
- Kurzfristig konzentriert man sich darauf, durch die Migration des Webhook-Backends, ein Redesign des User-Session-Caches, Anpassungen bei Authentifizierungs- und Autorisierungsabläufen sowie den Ausbau von Azure-basierter Compute-Kapazität Engpässe und Datenbanklast zu reduzieren
- Langfristig erhöht GitHub Widerstandsfähigkeit und Flexibilität durch Isolierung zentraler Dienste, weniger Single Points of Failure, die Migration von Teilen des Ruby-Monolithen nach Go, den Wechsel in die Public Cloud und die Absicherung eines Multi-Cloud-Pfads
- Sowohl die Merge-Queue-Regression vom 23. April als auch die Elasticsearch-Überlastung vom 27. April führten zu keinem Datenverlust; zugleich ergänzt GitHub seine Statusseite um Verfügbarkeitswerte und weitet die Offenlegung auch auf kleinere Störungen aus, um die Transparenz zu erhöhen
Hintergrund der Verfügbarkeitsmaßnahmen
- GitHub fasst nach den zwei jüngsten Ausfällen den Stand seiner Arbeiten zur Verbesserung von Verfügbarkeit und Zuverlässigkeit zusammen
- Seit Oktober 2025 läuft ein Plan zur Verzehnfachung der Kapazität; im Februar 2026 wurde deutlich, dass auf das 30-Fache der heutigen Größe hin entworfen werden muss
- Ein wesentlicher Hintergrund ist der Wandel in der Softwareentwicklung; seit der zweiten Hälfte des Jahres 2025 haben sich agentic development workflows stark beschleunigt
- Repository-Erstellung, Pull-Request-Aktivität, API-Nutzung, Automatisierung und Workloads großer Repositories nehmen alle schnell zu
Strukturelle Belastungen, die beim Skalieren sichtbar wurden
- Ein einzelner Pull Request kann zugleich Git-Repositories, Mergeability Checks, Branch Protection, GitHub Actions, Suche, Benachrichtigungen, Berechtigungen, Webhooks, APIs, Background Jobs, Caches und Datenbanken berühren
- In großem Maßstab können sich selbst kleine Ineffizienzen summieren und zu Warteschlangenstaus, der Verlagerung von Last durch Cache-Misses auf Datenbanken, Indexierungsverzögerungen, verstärktem Retry-Traffic und produkübergreifenden Auswirkungen langsamer Abhängigkeiten führen
- Die Prioritäten sind nun klar geordnet: Verfügbarkeit zuerst, dann Kapazität, dann neue Funktionen
- Parallel arbeitet GitHub daran, unnötige Arbeit zu reduzieren, Caches zu verbessern, zentrale Dienste zu isolieren, Single Points of Failure zu beseitigen und leistungssensible Pfade auf dedizierte Systeme zu verlagern
- Eine Kernaufgabe ist es, versteckte Kopplungen zu verringern, den Blast Radius zu begrenzen und Graceful Degradation sicherzustellen, damit Druck auf ein Subsystem nicht das Gesamtsystem zu Fall bringt
Derzeit laufende Verbesserungen
- Kurzfristig liegt der Fokus darauf, Engpässe zu beseitigen, die schneller als erwartet sichtbar wurden
- GitHub hat Webhooks auf ein anderes Backend außerhalb von MySQL verlagert, den Cache für Benutzersitzungen neu entworfen und auch Authentifizierungs- und Autorisierungsabläufe überarbeitet, um die Datenbanklast deutlich zu senken
- Im Zuge der Azure-Migration wurden außerdem mehr Compute-Ressourcen bereitgestellt
- Danach richtet sich der Fokus auf die Isolierung zentraler Dienste wie Git und GitHub Actions sowie auf die Reduktion von Single Points of Failure
- Durch eine detaillierte Analyse von Abhängigkeiten und Traffic-Schichten wurde ermittelt, was getrennt werden muss; Maßnahmen erfolgen nach Risikoreihenfolge, um die Auswirkungen verschiedenster Angriffe auf normalen Traffic zu minimieren
- Zudem wird die Migration von Teilen des für Performance und Skalierung sensiblen Codes vom Ruby-Monolithen nach Go beschleunigt
- Während der Wechsel aus bisherigen kleinen eigenen Rechenzentren in die Public Cloud voranschritt, begann GitHub langfristig zusätzlich einen Multi-Cloud-Pfad zu verfolgen
- Diese langfristige Maßnahme ist nötig, um die künftig erforderliche Widerstandsfähigkeit, geringe Latenz und Flexibilität zu erreichen
Große Repositories und Merge Queue
- Als schwierigere Skalierungsaufgabe als das bloße Wachstum der Repository-Zahl nennt GitHub die Zunahme großer Monorepos
- In den vergangenen drei Monaten wurden die Investitionen erhöht, um diesem Trend sowohl im Git-System als auch bei der Pull-Request-Erfahrung zu begegnen
- Auch Arbeiten an neuen API-Designs für höhere Effizienz und bessere Skalierbarkeit laufen und sollen in einem separaten Blogbeitrag vorgestellt werden
- Weil sie für Repositories mit Tausenden Pull Requests pro Tag wichtig ist, investiert GitHub außerdem in die Optimierung von Merge-Queue-Workloads
Jüngster Ausfall 1: Merge-Queue-Problem am 23. April
- Am 23. April trat eine Regression im Verhalten der Merge Queue für Pull Requests auf
- In einer Merge Queue mit Squash-Merge-Verfahren wurde ein fehlerhafter Merge Commit erzeugt, wenn eine Merge Group mehr als einen Pull Request enthielt
- In betroffenen Fällen führte dies dazu, dass nachfolgende Merges unbeabsichtigt Änderungen aus zuvor gemergten Pull Requests und bestehenden Commits zurücknahmen
- Im betroffenen Zeitraum waren 658 Repositories und 2.092 Pull Requests betroffen
- Die ersten Zahlen waren konservativ angesetzt, daher lagen die anfangs kommunizierten Werte leicht darüber
- Pull Requests, die außerhalb der Merge Queue gemergt wurden, waren nicht betroffen; ebenso wenig Merge-Queue-Gruppen mit Merge- oder Rebase-Verfahren
- Es gab keinen Datenverlust. Alle Commits blieben in Git gespeichert
- Allerdings war der Zustand des Default Branches in betroffenen Repositories fehlerhaft, und nicht alle Repositories konnten automatisch und sicher wiederhergestellt werden
- Incident Root Cause Analysis: Dort finden sich weitere Details
- Dieser Vorfall machte mehrere Prozessfehler sichtbar, und GitHub ändert diese Prozesse nun, damit sich Probleme dieser Art nicht wiederholen
Jüngster Ausfall 2: Suchproblem am 27. April
- Am 27. April fiel ein Elasticsearch-Subsystem aus, das mehrere suchbasierte Nutzererfahrungen abdeckt
- Zum betroffenen Bereich gehörten Teile der suchbasierten UIs für Pull Requests, Issues und Projects
- Die Root-Cause-Analyse ist noch nicht abgeschlossen und soll in Kürze veröffentlicht werden
- Nach bisherigem Stand geriet der Cluster in einen Überlastungszustand, sodass keine Suchergebnisse mehr zurückgegeben werden konnten
- Als mögliche Ursache der Überlastung wird auch ein Botnet-Angriff in Betracht gezogen, die Root-Cause-Analyse ist jedoch noch nicht abgeschlossen
- Es gab keinen Datenverlust, und Git-Operationen sowie APIs waren nicht betroffen
- Einige von der Suche abhängige UIs konnten jedoch überhaupt keine Ergebnisse mehr anzeigen, was erhebliche Verwirrung verursachte
- In diesem Systembereich war die vollständige Isolierung zur Beseitigung von Single Points of Failure noch nicht abgeschlossen; zuvor hatten andere Bereiche eine höhere Risikopriorität
- GitHub wendet nun dieselbe Analyse von Abhängigkeiten und dieselbe Reduktion des Blast Radius an, um Wahrscheinlichkeit und Auswirkungen solcher Ausfälle zu verringern
Mehr Transparenz bei Ausfällen
- Während der Störungen wurde deutlich, dass Kunden mehr Transparenz wünschen
- GitHub hat kürzlich die GitHub-Statusseite aktualisiert, sodass sie nun auch Verfügbarkeitswerte enthält
- Künftig sollen nicht nur große, sondern auch kleinere Störungen auf der Statusseite erscheinen, damit Nutzer nicht rätseln müssen, ob ein Problem auf ihrer Seite oder bei GitHub liegt
- Auch die Klassifizierung von Störungen wird weiter verbessert, damit Umfang und Reichweite leichter zu verstehen sind
- Parallel arbeitet GitHub daran, wie Kunden während Störungen besser Signale teilen und Probleme melden können
Zusage für die Zukunft
- GitHub verspricht bessere Verfügbarkeit, mehr Widerstandsfähigkeit, Skalierung für den Umfang künftiger Softwareentwicklung und transparentere Kommunikation
- Die Zahl der vom Vorfall am 23. April betroffenen Repositories wurde mit Stand vom 28. April 2026 aktualisiert
1 Kommentare
Hacker-News-Kommentare
GitHub hatte allein dieses Jahr bereits Dutzende Ausfälle, und Verfügbarkeit sowie Zuverlässigkeit sind im Vergleich zum Vorjahr spürbar schlechter geworden.
Inzwischen ist das so gravierend, dass man dafür praktisch ein Dashboard und eine Heatmap bauen könnte, und auf HN oder Reddit ist die GitHub-Instabilität fast schon zum Meme geworden.
Trotzdem zu sagen, die Prioritäten seien "availability, capacity, new features", wirkt erschreckend realitätsfern.
Die Prioritäten sollten jetzt bei 1, 2 und 3 ausschließlich availability sein, und man sollte mindestens 6 Monate lang über nichts anderes reden und nur das reparieren.
Vor 6 Monaten hieß es noch, die Azure-Migration habe oberste Priorität, deshalb werde Feature-Entwicklung verschoben; jetzt heißt es plötzlich wieder, Verfügbarkeit sei das Wichtigste, und das passt vorne und hinten nicht zusammen.
Damals wurde gesagt, die Kapazitätsgrenzen des Rechenzentrums in Virginia seien wegen der Nachfrage nach AI und Copilot geradezu "existential"; dass man wegen derselben Probleme immer noch taumelt, macht die Sache noch absurder.
Angeblich wurde die Feature-Entwicklung verschoben, trotzdem kommen weiterhin jede Woche neue Features und UI-Änderungen, und vor Kurzem wurde sogar wieder die Einzelansicht von Issues geändert.
Dass ein Unternehmen mit den Ressourcen von Microsoft immer wieder an derselben Stelle hängen bleibt, ist kaum zu glauben, und die Strategie, populäre Entwicklerdienste aufzukaufen und alle auf dieselbe Plattform zu ziehen, wirkt ebenfalls fragwürdig.
In großen Engineering-Organisationen schließen sich Prioritäten nicht gegenseitig aus, und Teams, die nicht direkt zur wichtigsten Priorität beitragen können, arbeiten möglicherweise weiter an anderen Features.
https://news.ycombinator.com/item?id=47912521
Dedizierte Hardware ist oft vorhersehbarer als die Cloud, und eine Entscheidung nach dem Motto "Gehen wir nicht zu Azure, kaufen wir lieber noch ein paar Racks" lag vielleicht gar nicht in der Kompetenz des GitHub-Managements.
GitHub ist keine Website, die alle 5 Minuten neu gestaltet werden muss, und manchmal wirkt es so, als würden Manager Features nur um der Features willen durchdrücken, um ihre Existenzberechtigung zu beweisen.
Das Ergebnis ist, dass man mit jedem weiteren kaputten Umbau die Nutzer eher abschreckt als anzieht.
Auch die Suche wurde massiv verschlechtert; ähnlich wie bei Google Search oder YouTube fragt man sich, warum alle funktionierende Suche immer weiter kaputtmachen.
Dazu kommt, dass Microsoft sowohl das fast aufgegebene Azure DevOps als auch GitHub hat, und bei beiden sind vor allem die Ticket-Systeme unerquicklich.
Ich war es leid, dass jedes Jira-Projekt anders konfiguriert ist, und inzwischen hört man schon Sätze wie: "Langsam vermisse ich sogar Jira."
Dieser Text ist schwer mit ernstem Gesicht zu lesen.
Große Zahlen auf unbeschrifteten Grafiken, Prioritäten, die nicht zum realen Nutzungserlebnis passen, und die Weigerung, das miserable Uptime-Niveau der letzten 12 Monate wirklich anzuerkennen, sind schwer zu ertragen.
Zwar fehlt unten links die Achsenbeschriftung, aber die Kernaussage, dass das Wachstum von 2023→2024→2025→2026 sehr schnell verläuft, kommt trotzdem an.
Man kann es so lesen, dass Anfang bzw. Ende 2026 ein Wachstum gemeint ist, das größer ist als das der vorherigen 3 Jahre zusammen, und auch ohne Achsenwerte erkennt man ungefähr den Trend.
Man muss dafür eine lineare Skala annehmen, aber in diesem Kontext scheint diese Annahme nicht unvernünftig.
Wenn ein Unternehmen viel stärker wächst als geplant, sind Kapazitätsprobleme unvermeidlich, und inzwischen reicht es offenbar nicht mehr, einfach nur mehr Hardware hinzuzufügen; es braucht Backend-Effizienzsteigerungen.
Die genannten Ziele scheinen sich größtenteils genau darauf zu richten.
https://x.com/kdaigle/status/2040164759836778878
Ich weiß nicht, ob manche einfach nicht glauben, dass das Wachstum gerade exponentiell ist, oder ob sie denken, eine Verzehnfachung pro Jahr sei gar nicht so schwer.
https://damrnelson.github.io/github-historical-uptime/
Wenn dort steht, man habe einen "multi cloud-Pfad begonnen", klingt das fast wie ein stillschweigendes Eingeständnis von Microsoft, dass Azure allein nicht die gewünschte Zuverlässigkeit liefern kann.
Für die Kundenbindung könnte das helfen.
Ursprünglich sollte der Betrieb fast ohne menschliches Eingreifen auskommen, heute sei es dagegen normal, dass jemand physisch an Racks oder VMs mit seriellen Konsolen herumarbeitet.
Den Link finde ich im Moment aber nicht.
Die aktivsten Leser sind montags bis donnerstags zwischen 9 und 11 Uhr Pacific unterwegs; am Wochenende gibt es zwar weniger Konkurrenz, aber auch weniger Beteiligung.
Der GitHub-CTO sitzt auch im Vorstand von Codepath.org, und wenn es dort heißt, man wolle "die erste AI-native Generation von Ingenieuren, CTOs und Gründern aufbauen", bekommt man eine ungefähre Ahnung, wo das Problem liegen könnte.
Gefühlt ist die GitHub-Stabilität deutlich schlechter geworden, und zuletzt kann man nicht einmal mehr den Daten vertrauen, die im Web angezeigt werden.
Seit gestern haben ich und einige Kollegen in mehreren Repositories bestätigt, dass PR-Listen unvollständig angezeigt werden.
Zum Beispiel steht bei https://github.com/gap-system/gap/pulls im Tab "Pull requests 78", aber in der Listenansicht erscheinen nur "35 open".
Dass 78 die korrekte Zahl ist, lässt sich auch mit
gh pr listbestätigen, trotzdem zeigt https://www.githubstatus.com weiterhin "all systems operational" an.Über die CLI tauchen sie in der Liste auf, aber über den suchbasierten Web-Pfad sind sie komplett verschwunden.
Der Support hat das Problem zwar bestätigt, seitdem herrscht aber Funkstille, und auf der Statusseite steht nichts dazu außer einem möglicherweise verwandten Vorfall vom 27.
In manchen Repositories scheint es zwischenzeitlich behoben worden zu sein, aber über mehrere Orgs und Repos hinweg lässt es sich weiterhin reproduzieren.
https://github.com/orgs/community/discussions/193388
Die fehlenden PRs habe ich nur gefunden, indem ich mich durch die Branch-Seite gewühlt habe.
Also womöglich weniger ein Bug als vielmehr eine aus Produktsicht sehr schlechte Entscheidung, um die Last auf der Infrastruktur zu senken.
Dass Daten zu neuen Repos/Issues/Commits der letzten Jahre offengelegt wurden, fand ich trotzdem interessant.
Es bestätigt, was viele von außen vermutet haben: Agenten verursachen bei GitHub plötzlich eine große zusätzliche Last.
Man bedient bereits eine riesige Nutzerbasis und wächst gleichzeitig wie ein Startup exponentiell, damit wird man fast zwangsläufig zur Zielscheibe, und es ist vermutlich auch organisatorisch schwer, schnell zu reagieren.
Andererseits hat man bei Talenten, Infrastruktur und Kapital natürlich weit mehr Spielraum als ein Startup.
Es gibt nur eine unbeschriftete Grafik und aktuelle Peak-Zahlen.
Bei diesen Grafiken fragt man sich wirklich, was da eigentlich dargestellt werden soll; das wirkt fast wie impressionistische Kunst.
Beim Commit-Graphen ist völlig unklar, warum nach großen Stufen jeweils ein flacheres Auslaufen folgt, warum diese Stufen nicht an konstanten Punkten auftreten und warum größere Sprünge manchmal mit einer geringeren Steigung einhergehen.
Die anderen Grafiken entwickeln sich wiederum in ganz anderen Formen, was es noch merkwürdiger macht.
Sie sollen nicht die realen Daten oder deren Bedeutung zeigen, sondern einfach nur vermitteln: "Irgendetwas geht nach oben."
Ich denke, föderierte Forges sind letztlich die Zukunft.
Repositories werden auf jeweils souveräner eigener Infrastruktur gehostet, dazu kommen globale IDs und föderierte Metadaten wie Issues und PRs.
Solche globalen Indizes lassen sich zudem vergleichsweise leicht betreiben, sodass Verfügbarkeit kein so großes Problem mehr sein müsste, und wir arbeiten selbst in diese Richtung.
Wenn man am Ende doch wieder auf Hosting durch Dritte setzt, entstehen wahrscheinlich erneut 1 bis 3 große Anbieter.
Und selbst wenn man wegen Verfügbarkeitsproblemen selbst hostet, hilft das wenig, solange Abhängigkeiten weiter bei großen Diensten wie GitHub liegen; deren Ausfälle lassen sich so nicht vermeiden.
Deshalb bleibt als realistische Lösung wie bisher vor allem, alles, was man nutzt, zu proxyn oder zu spiegeln.
Man kann dasselbe Repo auf GitHub, Codeberg und selbst gehostet vorhalten und nur die Konsistenz des Haupt-Branches sicherstellen.
Danach kann man von überall aus aktualisieren; man muss nur die Links im README sauber pflegen.
Wenn man stattdessen irgendeine andere Forge mit brauchbarer API oder Webhooks anschließen und denselben Komfort bekommen könnte, würde ich alles selbst hosten wollen.
Auch auf Agenten-Seite müsste dafür die Schnittstelle geöffnet werden, aber mit einer Plugin-Struktur ließe sich die GitHub-Abhängigkeit womöglich lösen und der Rest über MCP oder Skills abwickeln.
Ich selbst habe die großen Runner problemlos selbst gehostet und bin kürzlich zu Codeberg gewechselt; für kleine Cron-Jobs nutze ich die von Codeberg bereitgestellten Runner.
Dort gibt es für solche Zwecke sogar lazy runner.
Was gerade passiert, sieht ungefähr so aus:
Die Token-Subventionen haben offenbar genug Trainingsdaten eingesaugt, und das Geschäft mit den agentic junkies ist inzwischen groß genug, um das Flywheel aus eigener Kraft zu drehen; also kappt man sie jetzt und räumt verlustbringende Produkte ab.
https://news.ycombinator.com/item?id=47923357