GitHubs Krise im April 2026: Was 30x-Skalierung zeigt

GitHubs Krise im April 2026: Was 30x-Skalierung zeigt

Ich habe die Pull-Request-Liste zum dritten Mal aktualisiert. Leer. Das Repo hatte an diesem Morgen 14 offene PRs – ich hatte zwei davon vor dem Mittagessen überprüft – und jetzt zeigte mir die Seite die Art von Neuanfang, die man nur bei einem brandneuen Repo sieht. Mein erster Gedanke war nicht „GitHub ist down.“ Mein erster Gedanke war: „Hat jemand im Team alles geschlossen, während ich telefonierte?“

Dann habe ich das Terminal geöffnet. gh pr list. Alle 14 PRs. Genau dort. Nummern, Titel, Autoren, Entwurfszustände. Unberührt.

Diese Lücke – die Daten sind vorhanden, aber die Benutzeroberfläche kann sie nicht sehen – ist die gesamte Form der GitHub-Verfügbarkeitskrise, die die Entwicklergemeinschaft im April 2026 erlebt hat. Es handelt sich nicht um einen Ausfall, bei dem die Plattform umfällt und eine Statusseite rot wird. Es ist schlimmer. Es ist die Art, bei der alles so kaputt aussieht, dass Sie an Ihrer eigenen Arbeit zweifeln, während die zugrunde liegenden Systeme stillschweigend darauf bestehen, dass alles in Ordnung sei.

Am Ende der Woche hatte ich beobachtet, wie innerhalb von sieben Tagen zwei unterschiedliche Fehlermodi auf derselben Plattform auftraten, ich las dreimal das Update von Denn in der Geschichte dahinter geht es nicht wirklich um zwei Käfer. Es geht darum, was passiert, wenn der Engpass der globalen Softwareentwicklung durch eine Lastkurve erreicht wird, für die keine Infrastruktur ausgelegt ist – und die agentic AI-Tools, die Sie und ich jeden Tag verwenden, sind einer der Gründe dafür.

Die Woche, in der die Benutzeroberfläche von GitHub begann, Entwickler anzulügen

Lassen Sie mich die Szene richtig in Szene setzen, denn die Reihenfolge der Ereignisse zählt.

Das erste Anzeichen dafür, dass etwas strukturell nicht stimmte, kam am 31. März 2026, als GitHub das hatte, was ich seinen „echten“ Ausfall nennen würde – etwa sechs Stunden eingeschränkte Verfügbarkeit, verbunden mit einem Datenverlustereignis auf internen Systemen. Schmerzhaft, viel beachtet und etwas, mit dem sich jedes Ingenieursteam ein paar Mal im Jahrzehnt auseinandersetzt. Ich habe es als Einzelfall behandelt.

Dann geschah der 23. April. Beschädigung der Zusammenführungswarteschlange. Pull-Anfragen, die in die Warteschlange kamen, kamen auf der anderen Seite nicht immer sauber heraus. Einige Teams haben es geschafft, andere nicht. Wenn Sie in einem Hochgeschwindigkeits-Monorepo noch nie auf Zusammenführungswarteschlangen angewiesen waren, ist dies die Art von Fehler, die stillschweigend das Vertrauen in die gesamte Automatisierungsebene untergräbt – Ihr CI zeigt Grün an, die Zusammenführung sagt Zusammengeführt, und dann bemerkt jemand, dass der eigentliche Commit nicht so angekommen ist, wie er hätte sein sollen.

Am 27. April wurde es laut. Die Pull-Request-Listenansichten begannen, leere oder teilweise Ergebnisse zurückzugeben. Issue search broke. Die Filter im Projektboard wurden nicht mehr aufgelöst. Die ersten Berichte, die ich in den sozialen Medien sah, betrafen Leute, die ihren Kollegen vorwarfen, Arbeiten zu löschen, was genau die falsche, aber sehr menschliche Schlussfolgerung ist. Es dauerte ein paar Stunden, bis der Vorfallkanal von

Kein Datenverlust. Die wichtigsten Git-Operationen funktionierten die ganze Zeit. Der API lieferte immer wieder korrekte Ergebnisse an alle, die wussten, wie man die Web-Benutzeroberfläche umgeht und direkt nachfragt. Aber für die Millionen von Entwicklern, die GitHub hauptsächlich über github.com/org/repo/pulls erleben, hätte die Plattform genauso gut ausfallen können.

Das ist der Teil, zu dem ich immer wieder zurückgekehrt bin. Die Daten waren immer da. Die Infrastruktur, die die Daten findet, hat versagt. Und genau bei dieser Unterscheidung wird es interessant.

Warum „GitHub Is Down“ das falsche mentale Modell ist

Wenn Sie GitHub wie einen großen monolithischen Dienst behandeln, sehen die Vorfälle vom April 2026 zufällig aus. Sechs Stunden hier, ein Fehler in der Zusammenführungswarteschlange dort, ein Suchausfall vier Tage später. Von innen betrachtet ist es nichts dergleichen – es handelt sich um eine bestimmte Klasse von Fehlermodi, die wiederholt an einer bestimmten Stelle in der Architektur auftauchen.

Hier ist das mentale Modell, das mir geholfen hat, es zu verstehen.

Moderner GitHub besteht aus mindestens drei übereinander gestackten Diensten:

1. Die Git-Ebene – tatsächlicher Repository-Speicher, push/pull, Verzweigung, Zusammenführung. Dies ist der Teil, den niemand kaputt machen kann und der sich am besten gehalten hat.
2. Die Metadaten- und Workflow-Ebene – pull requests, Probleme, Projekte, Aktionen, Webhooks, Berechtigungen. Dies ist hauptsächlich Ruby-Monolith-Territorium, darunter MySQL und PostgreSQL.
3. Die Such- und Erkennungsebene – ElasticSearch, Indizierungspipelines, die Listenansichten und Filter, auf die Sie tatsächlich klicken.

Als sich der Vorfall am 27. April ereignete, wurde Schicht 1 nicht zerstört. Es wurde nicht einmal der Großteil von Schicht 2 zerstört. Es wurde Schicht 3 zerstört – und weil Schicht 3 die Benutzeroberfläche darstellt, die die meisten Entwickler verwenden, um ihre Arbeit zu finden, war der wahrgenommene Explosionsradius riesig, während der tatsächliche funktionale Explosionsradius begrenzt war.

Der Fehler in der Zusammenführungswarteschlange vom 23. April befand sich in Schicht 2. Der Datenverlust vom 31. März lag tiefer, näher an der Grenze zwischen Schicht 1 und Schicht 2. Drei verschiedene Fehler, drei verschiedene Schichten, alle innerhalb von vier Wochen. Das ist kein Pech. Das ist eine Lastkurve, die an mehreren Stellen gleichzeitig die Architektur übersteigt.

Und es ist der zweite Teil – die Lastkurve – dem ich den Rest dieses Beitrags widmen möchte. Denn die Obduktion von GitHubs CTO gibt im Wesentlichen das Offensichtliche zu: Von der Plattform wird verlangt, etwas zu tun, wofür sie nicht gebaut wurde, und derjenige, der darum bittet, liegt zum Teil bei uns.

Die 30x-Zahl, die jeden Engineer aufhorchen lassen sollte

Hier ist die Zeile aus der Führung von GitHub, die ich immer wieder lese. Bereits im Oktober 2025 startete das Team einen Kapazitätserweiterungsplan mit dem Ziel eines 10-fachen Wachstums – eine Zahl, die man für jedes Infrastrukturteam als konservativ-aggressiv bezeichnen würde. Bis Februar 2026, vier Monate später, lag das tatsächliche Ziel laut interner Modellierung bei 30x.

Lesen Sie das noch einmal. Nicht 10x leicht nach oben überarbeitet. Nicht 12x oder 15x. Verdreifachen Sie das ursprüngliche Ziel, nach nur wenigen Monaten neuer Daten.

Das öffentliche Update von GitHub nennt Spitzenwerte von 90 Millionen zusammengeführten pull requests, 1,4 Milliarden Commits und 20 Millionen neuen Repositories pro Monat. Sogar eine dieser Zahlen wäre für sich genommen ein Flex. Alle drei zusammen beschreiben eine Plattform, deren Lastprofil in Echtzeit neu geschrieben wird.

Was hat sich zwischen Oktober und Februar geändert? Zwei Dinge, und sie hängen zusammen.

Das erste liegt auf der Hand: Die Arbeitsabläufe bei der Agentenentwicklung gingen von der Neuheit zur Produktion. Ich habe diese Kurve aus dem Inneren meiner eigenen Arbeit beobachtet. Im dritten Quartal 2025 waren Agenten experimentell – Claude Code war neu, das Anthropic Agent SDK war gerade erst auf den Markt gekommen und die meisten Teams führten ein oder zwei automatisierte Arbeitsabläufe in der Produktion mit viel menschlicher Überprüfung aus. Im ersten Quartal 2026 führten dieselben Teams Flotten von Agenten. PR-erstellende Agenten. Testfixierungsmittel. Abhängigkeitsverhindernde Agenten. Dokumentationsagenten, die Zusammenführungen überwachten und Dokumente automatisch aktualisierten.

Jeder dieser Agenten ist ein unermüdlicher, niemals schlafender GitHub-Benutzer. Es öffnet PRs. Es pusht Commits. Es liest Probleme. Es trifft den API. Es löst Aktionsläufe aus. Während ein menschlicher Entwickler an einem starken Tag drei oder vier PRs öffnen könnte, könnte ein Agent dreißig öffnen – und eine Flotte von Agenten könnte Tausende in einer Organisation öffnen.

Die zweite Änderung ist struktureller Natur. Repositories selbst werden immer größer. Monorepos kommen häufiger vor. AI-unterstützte Refaktoren erzeugen größere Unterschiede. Generierter Code – ganze Gerüstanwendungen, die von Tools wie Claude Code in einer einzigen Eingabeaufforderung erstellt werden – erzeugt Commits, die Hunderte von Dateien gleichzeitig bearbeiten. Die Einheit „Änderung“ auf GitHub ist gewachsen.

Wenn Sie diese beiden Trends multiplizieren, erhalten Sie kein 10-faches Wachstum. Sie erhalten etwas, das einem zunehmend exponentiellen Wachstum nahekommt, das sich alle sechs bis acht Monate verdoppelt und keine Anzeichen einer Verlangsamung zeigt. Genau das hat das Kapazitätsteam von GitHub beschrieben.

Wenn Sie sich gefragt haben, warum sich Ihr CI dieses Jahr langsamer anfühlt, warum Ihre Webhook-Verzögerungen schleichend zunehmen, warum Ihre gh-CLI manchmal zehn Sekunden lang hängt, bevor sie ein Ergebnis zurückgibt, das sofort vorliegen sollte – das ist Ihre Antwort. Du bildest es dir nicht ein. Du spürst die Lastkurve.

Was uns der ElasticSearch-Ausfall tatsächlich sagt

Ich möchte speziell auf den 27. April zurückkommen, da der ElasticSearch-Fehler der diagnostisch nützlichste der drei Vorfälle ist. Es verrät uns etwas Konkretes darüber, wie ein Engpass dieser Größenordnung versagen kann.

ElasticSearch bei der Größe von GitHub ist kein Cluster, auf den Sie mehr Knoten werfen können. Es handelt sich um ein eng abgestimmtes verteiltes System, das alles von PR-Listenfiltern über Ausgabesuchen und Projektabfragen bis hin zur Repository-Erkennung unterstützt. Wenn ein Botnetz beschließt, es zu zerschlagen – und „Hämmern“ im Ausmaß von GitHub Zehntausende manipulierter Abfragen pro Sekunde aus einer kompromittierten Infrastruktur bedeutet –, sehen Sie nicht nur langsamere Antworten. Sie sehen, dass die Indexierungspipelines ins Hintertreffen geraten. Sie sehen die Sprechblase „Schreibwarteschlangen“. Sie sehen, dass der Cluster mehr Zeit damit verbringt, seinen eigenen Gegendruck zu verwalten, als echte Anfragen zu beantworten.

Die Abhilfe besteht darin, Indizes neu zu erstellen, missbräuchlichen Datenverkehr zu drosseln und den Cluster langsam wieder in Betrieb zu nehmen. Nichts davon ist schnell. Nichts davon ist glamourös. Und während dies geschieht, sieht der Rest der Plattform gut aus, während eine entscheidende Ebene des Benutzererlebnisses beeinträchtigt ist.

Was dies offenbart – und was GitHub nun öffentlich anerkannt hat – ist, dass das Suchsubsystem ein Single Point of Failure war, der noch nicht vom Rest der Plattform isoliert war. Die Zuverlässigkeitsarbeit wurde zuerst anderswo priorisiert, an Orten, die als risikoreicher galten, und die Suche zog den Kürzeren. Der 27. April ließ diese Priorisierung im Nachhinein falsch erscheinen, was die grausame Arithmetik der Reaktion auf Vorfälle ist – jede Obduktion ist auch eine Kritik daran, gegen welche Brände Sie sich entschieden haben, nicht zuerst zu kämpfen.

Darin liegt eine Lektion für Entwickler verborgen, und so etwas ist leicht zu nicken, aber schwer umzusetzen: Der Explosionsradius Ihrer Anwendung ist nicht derselbe wie der Fußabdruck Ihrer Anwendung. Die Daten von Da die meisten ihrer Benutzer GitHub jedoch über eine suchgesteuerte Benutzeroberfläche erleben, wurde ein Fehler auf der Suchebene zu einem Ereignis auf Plattformebene in der gelebten Erfahrung jedes Einzelnen. Das, was kaputt ging, war nicht das Wichtigste in ihrer Architektur. Es war das Sichtbarste.

Ich habe letzte Woche damit begonnen, meine eigenen Systeme mit dieser Linse zu prüfen. Welche Subsysteme würden bei einem Ausfall dafür sorgen, dass der Rest meiner Anwendung kaputt aussieht, auch wenn das nicht der Fall ist? Die Antwort ist unangenehm. Es gibt mehr davon, als mir lieb ist.

Die CTO-Roadmap, entschlüsselt

Die Antwort von GitHub auf all das kam in Form eines öffentlichen Updates von CTO, und ich möchte es sorgfältig durchgehen, weil die Sprache echte Arbeit leistet. Das bedeutet nicht nur: „Es tut uns leid, wir werden die Kapazität erhöhen.“ Es handelt sich um eine strukturierte Darstellung dessen, wie die nächsten 12 bis 24 Monate des GitHub-Engineerings aussehen werden – und die Form verrät Ihnen etwas darüber, wohin sich die gesamte Branche entwickelt.

So wie ich sie lese, ist die Roadmap in fünf Prioritäten unterteilt.

1. Verfügbarkeit vor Kapazität, Kapazität vor Funktionen. Dies ist die Neuordnung der Überschrift. Für den größten Teil der Geschichte von GitHub hatte die Feature-Geschwindigkeit oberste Priorität – Copilot, Codespaces, Aktionen, Projekte v2, Agenten-Workflows, alles in aggressiven Zeitplänen ausgeliefert. Die neue Reihenfolge ist eindeutig: Lassen Sie zuerst die Lichter an, stellen Sie dann sicher, dass die Lichter auch bei 30-facher Belastung an bleiben, und versenden Sie dann die neuen Dinge. Jeder, der ein Infrastrukturteam leitet, hat diese Neuordnung schon einmal erlebt, normalerweise nach einem schlechten Quartal. Es ist der richtige Anruf. Es ist auch ein Signal dafür, dass die Arbeit an einigen Funktionen sichtlich langsamer wird.

2. Reduzieren Sie unnötige Arbeit und verbessern Sie das Caching. Das hört sich langweilig an, bis Sie sich an das PostgreSQL-Beispiel erinnern, das GitHub gegeben hat: Die Ratenbegrenzung über nicht protokollierte Tabellen funktioniert gut bei unter 1.000 Anfragen pro Sekunde, aber bei 10.000 RPS müssen Sie davor Redis zwischenspeichern, sonst schmilzt die Datenbank. Jede Schicht des Stacks hat Schwellenwerte wie diesen. Bei der Skalierung wird nicht Hardware hinzugefügt – es geht darum, jede Stelle zu erkennen, an der ein billiges Muster nur funktionierte, weil die Last niedrig war, und es neu aufzubauen.

3. Isolieren Sie kritische Dienste und begrenzen Sie den Explosionsradius. Das hätte der 27. April verhindern sollen. Die Arbeit hier ist architektonischer Natur: Stellen Sie sicher, dass die Suche fehlschlagen kann, ohne dass PR-Seiten beschädigt werden, stellen Sie sicher, dass die Webhook-Bereitstellung beeinträchtigt werden kann, ohne dass Aktionen heruntergefahren werden, und stellen Sie sicher, dass auf einen Mandanten angewendete Ratenbegrenzungen nicht auf einen anderen übergreifen. Jeder Eintrag „X isolieren“ auf dieser Liste ist auch ein Eingeständnis, dass X zuvor nicht isoliert wurde.

4. Migrieren Sie leistungskritische Pfade vom Ruby-Monolithen nach Go. Dies ist das taktischste und am stärksten belastete Element. Der Ruby on Rails-Monolith war von Anfang an die Identität von GitHub – es gibt einen berühmten internen Witz, dass GitHub der Rails-Monolith mit einigen zusätzlichen Services ist. Die Verlagerung von Hot Paths auf Go (und die Verlagerung der Webhook-Bereitstellung von MySQL auf alternative Backends, was sie ebenfalls anprangerten) ist die Art von Arbeit, die Jahre dauert und die Einstellung der Ingenieure zur Codebasis verändert.

5. Azure-Migration und Multi-Cloud-Bereitschaft. Microsoft besitzt GitHub, daher stand die Azure-Migration immer bevor. Aber der Multi-Cloud-Rahmen ist neu und wichtig – er deutet darauf hin, dass die Führung von GitHub nicht möchte, dass der regionale Vorfall eines einzelnen Cloud-Anbieters zum Vorfall von GitHub wird.

Wenn Sie diese Roadmap lesen und schielen, handelt es sich um das gleiche Spielbuch, das jede schnell wachsende Plattform der letzten fünfzehn Jahre verwendet hat. Twitter hat es nach der Fail-Wale-Ära veröffentlicht. Stripe führt es kontinuierlich aus. AWS führt es über Jahrzehnte hinweg in Zeitlupe aus. Das Interessante daran ist nicht, dass GitHub dies tut. Der interessante Teil ist das Timing und der Auslöser.

Warum Agentic AI-Workflows die Entwicklungsinfrastruktur neu gestalten

Hier ist der Teil, der am direktesten mit dem zusammenhängt, worüber ich jede Woche schreibe. Der Grund dafür, dass GitHub sein Wachstumsziel in vier Monaten von 10x auf 30x revidieren musste, liegt nicht darin, dass menschliche Entwickler plötzlich dreimal produktiver werden. Es liegt daran, dass sich die Einheit von „GitHub-Benutzer“ ändert.

Im letzten Jahrzehnt war ein GitHub-Benutzer eine Person. Diese Person öffnete ein paar PRs pro Tag, überprüfte noch ein paar weitere, pushte Commits in konzentrierten Schüben während der Arbeitszeit und ging nach Hause. Ihr Belastungsprofil war stoßweise, an die Zeitzone gebunden und letztlich davon abhängig, wie viele Tastenanschläge ein Mensch ausführen kann.

Der neue GitHub-Benutzer ist teilweise oder vollständig ein Agent. Es schläft nicht. Es gibt keine Arbeitszeiten. Es generiert jedes Mal einen PR, wenn CI einen fehlerhaften Test markiert, eine Abhängigkeit veraltet ist, eine Dokumentationsabweichung erkannt wird oder ein Feature-Flag bereinigt werden muss. Es führt keine kleinen Commits durch, sondern strukturierte, vom Tool generierte Commits, die oft viele Dateien gleichzeitig betreffen.

Wenn Sie die stoßweise begrenzte menschliche Auslastung durch eine kontinuierlich unbegrenzte Agentenauslastung ersetzen, passieren drei Dinge gleichzeitig mit Ihrer Infrastruktur:

• Spitzen-zu-Durchschnitts-Verhältnisse werden komprimiert. GitHub hatte früher Nächte und Wochenenden. Das geht nicht mehr. Die Grenze zwischen „Spitzenlast“ und „Hintergrundlast“ verschwindet, und Sie müssen so planen, dass die Spitze der neue Durchschnitt ist.
• Die mittlere Objektgröße wächst. Agenten erzeugen größere Unterschiede und umfangreichere PR-Beschreibungen. PR-berührende Subsysteme – Diff-Rendering, Zusammenführungsprüfungen, Review-Threading – zahlen dafür mit mehr CPU, mehr Speicher, mehr Indexarbeit.
• Spitzen der Kaskadenwahrscheinlichkeit. Ein unzuverlässiger Webhook bedeutete früher eine leicht verzögerte Benachrichtigung. Wenn sich Agenten in der Schleife befinden, kann ein instabiler Webhook auf eine blockierte Automatisierungspipeline hinweisen, was bedeutet, dass der Agent es erneut versucht, was mehr API-Aufrufe bedeutet, was eine höhere Belastung des Systems bedeutet, das bereits Probleme hatte.

Ich habe jedes davon in meiner eigenen Arbeit gespürt. Im letzten Quartal habe ich ungefähr vier Claude Code-Agenten parallel in einem Kundenprojekt ausgeführt – einer schrieb Tests, einer reparierte sie, einer aktualisierte die Dokumentation, einer überprüfte PRs. Jeder Agent fühlte sich einzeln billig an. Zusammen generierten sie an einem Nachmittag mehr GitHub API Traffic, als ich in einer Woche manuell generiert hätte. Und ich war einer der Entwickler. Multiplizieren Sie das mit der globalen Agenten-Entwicklerpopulation, die sich ungefähr im selben Zeitraum, in dem sich die Auslastung von GitHub verdoppelte, von „Early Adopters“ zu „Mainstream“ entwickelt hat.

Dies ist die wahre Geschichte der GitHub-Verfügbarkeitskrise vom April 2026. Nicht „GitHub hatte eine schlechte Woche.“ Es heißt: „Das Lastmodell, für das die Plattform entwickelt wurde, wurde durch ein anderes Lastmodell ersetzt, und die architektonische Schuld dieser Diskrepanz wurde öffentlich zur Schau gestellt.“

Wenn Sie genauer beschreiben möchten, wie agentische Arbeitsabläufe in diesem Jahr zur dominierenden Kraft auf Entwicklungsplattformen wurden, habe ich die früheren Anzeichen dafür im Anthropic Agent SDK-Leitfaden und im Claude Code agentic OS Framework behandelt – der rote Faden bei all dem ist, dass die Tools, die wir als Produktivitätsgewinne feiern, auch Infrastruktur-Stresstests sind, und GitHub ist die erste große Plattform, bei der der Gesetzentwurf laut genug fällig wurde, um in die Schlagzeilen zu kommen.

Was dies für die Art und Weise bedeutet, wie Sie auf GitHub aufbauen

Lassen Sie mich taktisch vorgehen. Wenn Sie etwas entwickeln, das von GitHub abhängt – und wenn Sie im Jahr 2026 ein arbeitender Entwickler sind, dann gibt es fünf konkrete Anpassungen, die es wert sind, in den nächsten 30 Tagen vorgenommen zu werden.

Trennen Sie zunächst „GitHub ist aktiv“ von „GitHub UI ist aktiv“ in Ihrer Überwachung. Der Vorfall vom 27. April hat gezeigt, dass es sich um unterschiedliche Zustände handelt. Wenn Ihr Werkzeug darauf wartet, dass die Statusseite GitHub rot wird, bevor es Probleme umgeht, kommen Sie zu spät. Fügen Sie direkte API-Zustandsprüfungen für die spezifischen Endpunkte hinzu, von denen Ihr Workflow abhängt – gh pr list für ein bekanntes Repo, eine Suchabfrage, von der Sie wissen, dass sie Ergebnisse liefern sollte – und behandeln Sie eine teilweise Verschlechterung als Aktionssignal, nicht nur als Informationssignal.

Zweitens: Verlassen Sie sich auf den API und die CLI, nicht auf die Web-Benutzeroberfläche, für jeden Workflow, den Sie nicht verlieren dürfen. Der pull requests existierte den ganzen 27. April hindurch. Die CLI sah sie die ganze Zeit. Wenn das Vorfall-Playbook Ihres Teams davon abhängt, dass Menschen durch PR-Listenansichten klicken, bricht Ihr Vorfall-Playbook zusammen mit der Suchebene ab. Wenn das Playbook über gh und API weitergeleitet wird, ist dies nicht der Fall.

Drittens überprüfen Sie Ihre Agenten auf Wiederholungsverhalten. Jeder Agenten-Workflow, den ich jemals ausgeliefert habe, hat irgendwann während eines nachgelagerten Vorfalls einen Wiederholungssturm gezeigt, was den Vorfall für alle, auch für sich selbst, verschlimmert hat. Exponentielles Backoff, Jitter und Leistungsschalter sind für Agenten, die GitHub berühren, nicht optional. Wenn Ihr Agent nicht über alle drei verfügt, wird der nächste Ausfall für Sie und GitHub schwieriger.

Viertens: Behandeln Sie suchgestützte Ansichten grundsätzlich als weniger zuverlässig als direkte Suchvorgänge. Dies ist eine langfristige Architekturlektion, keine GitHub-spezifische. Immer wenn eine Benutzeroberfläche von einem Suchindex abhängt, sind Sie auf ein System angewiesen, dessen Wiederherstellungszeiten in Stunden gemessen werden. Wenn Ihr Workflow direkte Suchvorgänge verwenden kann (PR nach Nummer, Commit nach SHA, Issue nach ID), bevorzugen Sie diese. Speichern Sie suchgestützte Abfragen für wirklich explorative Anwendungsfälle.

Fünftens – und das ist das, was die meisten Teams überspringen – fügen Sie einen „GitHub Graceful Degradation“-Modus zu allem hinzu, was Sie erstellen. Was macht Ihr Tool, wenn GitHub aktiv, aber langsam ist? Wenn Teilergebnisse zurückgegeben werden? Wenn Webhooks um fünf Minuten statt um fünf Sekunden verzögert werden? Die meisten Tools, die ich gesehen habe, lauten entweder „GitHub funktioniert“ oder „Alles explodiert“. Es gibt einen riesigen Mittelweg, für den es sich zu entwerfen lohnt.

Was ich falsch gemacht habe und was ich mir als nächstes ansehe

Ich bin ehrlich zu einer Sache, von der ich angenommen habe, dass sie hierher kommt. Als sich der Vorfall vom 31. März ereignete, betrachtete ich ihn als einen Einzelfall und ging weiter. Ich habe es nicht mit der Lastkurve verbunden. Ich hatte nicht damit gerechnet, dass wir innerhalb von vier Wochen zwei weitere Vorfälle auf verschiedenen Ebenen derselben Plattform erleben würden. Die Beschädigung der Zusammenführungswarteschlange vom 23. April wurde bei mir kaum registriert, da an diesem Tag keines meiner Projekte Zusammenführungswarteschlangen verwendete. Am 27. April war das Muster nicht mehr zu leugnen.

Die Lektion, die ich daraus ziehe, ist, dass Infrastrukturvorfälle dieser Größenordnung normalerweise nicht als einzelner dramatischer Ausfall auftreten. Sie stellen eine Ansammlung zusammengehöriger kleinerer Fehler dar, die jeweils einzeln erklärbar erscheinen und nur dann einen Sinn ergeben, wenn man sie als eine Geschichte liest. Wenn Sie auf den einen großen Ausfall warten, verpassen Sie die Warnschüsse.

Was ich mir für den Rest des Jahres 2026 ansehe:

• Ob die Kapazitätserweiterung von GitHub der Lastkurve voraus bleibt. Das 30-fache Ziel ist fett, aber auch die Kurve bewegt sich. Wenn sich die Agentenabläufe in der zweiten Jahreshälfte wieder beschleunigen, wandert das Ziel mit. - Ob die Konkurrenz ernst wird. GitLab, Codeberg, Forgejo und selbst gehostete Gitea-Instanzen profitieren alle von jeder anhaltenden Zuverlässigkeitslücke bei GitHub. Ich erwarte keine Massenmigration, aber ich erwarte die Frage „Ist GitHub immer noch die Standardeinstellung?“ Diese Frage wird in mehr Architekturbesprechungen aufgeworfen als noch vor sechs Monaten. - Ob Agenten-Workflows selbst höflicher werden. Es gibt ein Argument dafür, dass die Agenten, die diese Last erzeugen, intelligenter vorgehen könnten – Stackverarbeitung, Zwischenspeicherung, Berücksichtigung von Backoffs, Vermeidung unnötiger Abfragen. Die erste Welle von Agententools, die auf Leistungsfähigkeit optimiert sind.

Die zweite Welle muss optimiert werden, um ein guter Bürger in einer gemeinsamen Infrastruktur zu sein. - Ob die Monolith-to-Go-Migration rechtzeitig versendet wird. Dies ist der Punkt mit der höchsten Hebelwirkung auf der Roadmap von GitHub und auch der langsamste. Jahrelange Arbeit. Wenn sie es gut ausführen, sieht GitHub bei 30-facher Last gut aus. Wenn nicht, werden wir im Jahr 2027 dasselbe Gespräch über einen anderen Vorfall führen.

Ich komme immer wieder darauf zurück, dass GitHub in dieser Größenordnung nicht mehr nur ein Produkt ist. Es ist Infrastruktur. Es ist der Engpass, durch den ein bedeutender Prozentsatz der weltweiten Software auf dem Weg von der Idee bis zur Produktion fließt. Wenn Ihr Engpass einen schlechten Monat hat, wirken sich die Folgen auf schwer messbare, aber leicht spürbare Weise nach außen aus.

Häufig gestellte Fragen

Was hat den GitHub-Pull-Request-Fehler im April 2026 verursacht?

Der Pull-Request-Sichtbarkeitsfehler vom 27. April wurde dadurch verursacht, dass der ElasticSearch-Cluster, der suchgestützte Ansichten unterstützt, überlastet wurde, angeblich unter Botnet-gesteuertem Datenverkehr. PRs schienen in Listenansichten zu fehlen, da diese Ansichten von Suchindizes abhängen, aber die zugrunde liegenden Daten gingen nie verloren und blieben über GitHub API und CLI zugänglich. Die Aufschlüsselung der Architektur finden Sie oben unter „Warum GitHub ausgefallen ist, ist das falsche mentale Modell“.

Hat GitHub während der Vorfälle im April 2026 Daten verloren?

Nein. Keiner der Vorfälle vom April 2026 – Beschädigung der Zusammenführungswarteschlange am 23. April, ElasticSearch-Überlastung am 27. April – führte zu Datenverlust. Kern-Git-Vorgänge, Repositorys und API funktionierten weiterhin. Bei dem früheren Vorfall vom 31. März 2026 kam es zu einem Datenverlust mit etwa sechs Stunden eingeschränkter Verfügbarkeit.

Was ist der 30-fache Skalierungsplan von GitHub?

Der Plan umfasst die Isolierung kritischer Dienste, die Migration von Hot Paths von Ruby nach Go, die Verschiebung von Webhooks von MySQL und die Fortsetzung der Azure-Migration. Die vollständige Aufschlüsselung finden Sie oben unter „Die 30-fache Zahl, die jeden Ingenieur kalt machen sollte“.

Wie wirkt sich der Agent AI workflows auf die Infrastruktur von GitHub aus?

Agenten-Workflows ersetzen die stoßweise, in der Zeitzone verankerte menschliche Belastung durch eine kontinuierliche, unbegrenzte Agentenbelastung. Agenten öffnen PRs, pushen Commits und rufen APIs ohne Schlafzyklen auf, wodurch das Spitzen-zu-Durchschnitts-Verhältnis komprimiert, die mittlere Objektgröße erhöht und die Kaskadenwahrscheinlichkeit bei Vorfällen erhöht wird. Das CTO-Update von GitHub nennt direkt die Beschleunigung der Agenten-Workflows seit Ende 2025 als Haupttreiber des überarbeiteten Skalierungsziels.

Sollte ich nach April 2026 von GitHub migrieren?

Für die meisten Teams nein. Die Git-Kernschicht von GitHub blieb während der Vorfälle im April 2026 stabil und keine öffentliche Roadmap von GitLab, Codeberg oder Forgejo entspricht derzeit der Feature-Oberfläche von GitHub. Der richtige Schritt besteht darin, Ihre Tools gegen eine teilweise GitHub-Verschlechterung zu härten – bevorzugen Sie API und CLI gegenüber der Web-Benutzeroberfläche für kritische Arbeitsabläufe, fügen Sie elegante Verschlechterungsmodi hinzu und prüfen Sie Ihre Agenten auf Wiederholungsstürme. Siehe „Was dies für die Art und Weise bedeutet, wie Sie auf GitHub aufbauen“ oben.

Lassen Sie uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io