GitHub war am 17. August fast 8 Stunden offline
GitHub.com erlitt am 17. August 2026 einen Ausfall von 7 Stunden und 47 Minuten, von 13:28 bis 21:15 UTC, der nahezu jeden zentralen Entwickler-Workflow auf der Plattform beeinträchtigte. Erhöhte Fehlerraten und Latenzen trafen gleichzeitig Issues, Pull Requests, die REST- und GraphQL-APIs, GitHub Actions und GitHub Copilot, sodass die Störung nicht auf eine einzelne Funktion beschränkt blieb. GitHubs eigenes Post-Mortem, veröffentlicht auf github.blog unter dem Titel "The August 17 outage and the work ahead", beziffert die maximale Fehlerquote auf rund 20% weltweit und rund 50% speziell bei Archiv- und Raw-Datei-Downloads. The Register, TechTimes und dev.to bestätigten Zeitverlauf und Umfang in ihrer eigenen Berichterstattung.
| Kennzahl | Wert |
|---|---|
| Beginn (UTC) | 13:28 |
| Ende (UTC) | 21:15 |
| Dauer | 7 Stunden 47 Minuten |
| Maximale Fehlerquote, weltweit | ~20% |
| Maximale Fehlerquote, Archiv/Raw-Downloads | ~50% |
Ursache war ein Proxy an seiner Grenze, kein fehlerhafter Deploy
GitHubs Post-Mortem stellt klar fest, dass der Ausfall nicht durch ein Code- oder Konfigurations-Deployment verursacht wurde; es handelte sich um ein Kapazitäts- und Überwachungsproblem in der eigenen Netzwerkinfrastruktur des Unternehmens. Auslöser war ein Istio-Service-Mesh-Sidecar-Proxy in einem Rechenzentrum in Central US, der sein Concurrency-Limit erreichte, als der Traffic in einem neuen Spitzenmuster eintraf, für das das System nicht dimensioniert war. Ein Service-Mesh-Sidecar sitzt neben jeder Service-Instanz und verwaltet deren Netzwerkverkehr, sodass bei Erreichen einer harten Grenze unter unerwarteter Last alles, was darüber geroutet wird, gleichzeitig ausfällt statt sich allmählich zu verschlechtern.
Ein falsch konfigurierter Alarm bedeutete, dass niemand es kommen sah
Eine interne Überwachungsrichtlinie war falsch konfiguriert und alarmierte GitHubs Ingenieure nicht, als sich der Sidecar-Proxy seiner Concurrency-Grenze näherte, sodass die Warnung, die eine Reaktion vor den ersten Nutzerbeschwerden hätte auslösen sollen, schlicht ausblieb. Diese Lücke ist ebenso wichtig wie das Concurrency-Limit selbst: Eine Kapazitätsgrenze, die früh erkannt wird, ist ein stilles Upgrade, eine Grenze, die erst nach sichtbaren Nutzerfehlern erkannt wird, wird zu einem mehrstündigen Vorfall. GitHub erklärt, die Behebung dieser Überwachungslücke sei Teil der im Titel des Post-Mortems genannten "work ahead".
GitHubs eigene Retry-Logik, vor allem von VS Code, verschärfte den Ausfall
Optimistische clientseitige Retry-Logik im gesamten GitHub-Ökosystem machte aus einem überlasteten Proxy eine plattformweite Kaskade, und GitHub nennt einen Retry-Sturm von VS-Code-Clients ausdrücklich als wesentlichen Faktor dafür, wie schlimm der Ausfall wurde. Wenn eine Anfrage fehlschlägt und ein Client sofort ohne Backoff erneut anfragt, scheitert er nicht nur erneut, sondern fügt einem bereits überlasteten System eine weitere Anfrage hinzu, und multipliziert über Millionen im Hintergrund aktive VS-Code-Installationen wurde aus einem eingegrenzten Proxy-Problem ein plattformweites. Genau dieses Detail macht aus dem Vorfall keine reine Geschichte über GitHubs Infrastruktur, sondern eine Geschichte darüber, wie jeder Client jeder API gebaut sein sollte.
Für jedes Unternehmen mit Pipeline über GitHub war dies ein 8-Stunden-Blackout
Die meisten Unternehmen betrachten einen GitHub-Ausfall als Ärgernis für Entwickler, über das man sich beim Warten beschwert, doch für jedes Unternehmen, das GitHub Actions und Copilot still in seine Release-Pipeline eingebaut hat, bedeuten 7 Stunden und 47 Minuten ohne GitHub 7 Stunden und 47 Minuten, in denen man keinen Hotfix ausliefern, keinen Sicherheitspatch mergen und, falls Copilot Teil des Workflows ist, ein KI-gestütztes Coding-Werkzeug mitten in der Aufgabe verlieren kann. Das ist ein Konzentrationsrisiko auf einen einzigen Anbieter, versteckt hinter dem, was wie "einfach GitHub nutzen" aussieht, und es taucht auf keiner Budgetzeile auf wie ein Software-Abo. Die schärfere Lehre ist der Retry-Sturm: Wenn GitHubs eigene Client-Software einen Ausfall durch aggressive Retries ohne Backoff verschlimmert hat, sollte jedes Unternehmen, das eigene Systeme gegen Drittanbieter-APIs baut, seine eigene Retry-Logik auf dasselbe Fehlverhalten prüfen, statt es allein als GitHubs Problem abzulegen.
Weiterlesen: Wiz-KI-Agent hackte Snowflake und beschuldigte Copilot | Ihr Zweiter Git-Host Schaltete Sich Selbst Ein
