GitHub kämpft mit Skalierung: CTO erklärt zwei Incidents und
TL;DR: GitHub CTO Vlad Fedorov hat am 28. April 2026 ein detailliertes Statement zu zwei kritischen Incidents und zu GitHubs technischer Transformation veröffentlicht – ein seltener Einblick in die Architektur-Entscheidungen hinter einer der größten Developer-Plattformen der Welt.
Zwei Incidents innerhalb weniger Tage haben GitHub unter Druck gesetzt: Am 23. April führte ein Bug in der Merge Queue zu falschen Merge-Commits bei Squash-Merges mit mehr als einem Pull Request – 230 Repositories und 2.092 Pull Requests waren betroffen, Datenverlust gab es keinen, aber betroffene Default-Branches mussten manuell korrigiert werden. Am 27. April legte ein überlasteter Elasticsearch-Cluster weite Teile der Such-basierten UI lahm – vermutlich ausgelöst durch einen Botnet-Angriff. Git-Operationen und APIs blieben dabei intakt, die Nutzererfahrung war dennoch erheblich beeinträchtigt. GitHub-CTO Vlad Fedorov hat beide Incidents öffentlich eingeräumt und entschuldigt sich klar für den Impact.
Was ist neu?
Der eigentliche Kern des Beitrags ist kein klassisches Post-Mortem, sondern ein strategisches Update zur Plattform-Architektur. GitHub startete im Oktober 2025 mit einem Plan, die Kapazität auf das 10-Fache zu skalieren – bis Februar 2026 wurde dieses Ziel bereits auf 30X angehoben. Treiber ist die massive Beschleunigung durch agentische Entwicklungs-Workflows seit Ende 2025: Die Plattform verzeichnete Peaks von 90 Millionen gemergten Pull Requests, 1,4 Milliarden Commits und 20 Millionen neu erstellten Repositories pro Monat.
Technisch reagiert GitHub mit mehreren parallelen Maßnahmen: Webhooks werden aus MySQL herausmigriert, Session-Caches und Auth-Flows werden neu gestaltet, um Datenbank-Last zu reduzieren. Kritische Services wie Git und GitHub Actions werden von anderen Workloads isoliert, um den Blast Radius bei Incidents zu begrenzen. Performance-sensitiver Code wird schrittweise vom Ruby-Monolith in Go migriert. Und der bestehende Weg in die Azure-Cloud wird um einen Multi-Cloud-Ansatz ergänzt – als längerfristige Maßnahme für Resilienz und niedrige Latenz. Außerdem hat GitHub die Status-Seite aktualisiert: Sie zeigt nun Availability-Kennzahlen, und GitHub verpflichtet sich, künftig alle Incidents – große wie kleine – zu kommunizieren.
Was bedeutet das für Teams und Tech Leads?
Für Teams und Tech Leads ist relevant, dass GitHub hier nicht nur Incidents erklärt, sondern eine fundamentale Architektur-Transformation offenlegt. Die Kombination aus Monolith-Decomposition (Ruby → Go), Service-Isolation, Blast-Radius-Reduktion und Multi-Cloud ist ein Lehrbuchbeispiel für das Skalieren hochbelasteter Distributed Systems – und ein Signal, dass die Plattform-Reliability in einer Phase massiver Lastspitzen strukturell neu aufgestellt wird. Die öffentliche Transparenz über konkrete Zahlen (230 betroffene Repos, 30X-Skalierungsziel) ist ungewöhnlich für einen Plattformbetreiber dieser Größe und zeigt, dass GitHub den Druck der Community ernst nimmt. Für Entscheider, die GitHub als kritische Infrastruktur einsetzen, ist die angekündigte Verbesserung der Status-Page-Kommunikation ein unmittelbar relevanter Schritt.
