GitHub lag op 17 augustus bijna 8 uur plat
GitHub.com kampte op 17 augustus 2026 met een storing van 7 uur en 47 minuten, van 13:28 tot 21:15 UTC, die vrijwel elke centrale ontwikkelworkflow op het platform raakte. Verhoogde foutpercentages en latency troffen tegelijk Issues, Pull Requests, de REST- en GraphQL-API's, GitHub Actions en GitHub Copilot, dus de verstoring bleef niet beperkt tot één functie. GitHub's eigen postmortem, gepubliceerd op github.blog onder de titel "The August 17 outage and the work ahead", noemt een piekfoutpercentage van rond de 20% site-breed, en rond de 50% specifiek voor archief- en raw-bestandsdownloads. The Register, TechTimes en dev.to bevestigden tijdlijn en omvang in hun eigen berichtgeving over het incident.
| Metriek | Waarde |
|---|---|
| Start (UTC) | 13:28 |
| Einde (UTC) | 21:15 |
| Duur | 7 uur 47 minuten |
| Piekfoutpercentage, site-breed | ~20% |
| Piekfoutpercentage, archief/raw-downloads | ~50% |
De oorzaak was een proxy op zijn limiet, geen mislukte deploy
GitHub's postmortem stelt expliciet dat de storing niet werd veroorzaakt door een code- of configuratiedeploy; het was een capaciteits- en monitoringprobleem binnen de eigen netwerkinfrastructuur van het bedrijf. De trigger was een Istio service-mesh sidecar-proxy in een datacenter in Central US die zijn concurrency-limiet bereikte toen het verkeer aankwam in een nieuw piekpatroon waarvoor het systeem niet was gedimensioneerd. Een service-mesh sidecar staat naast elke service-instantie om het netwerkverkeer ervan te beheren, dus wanneer er één een harde limiet raakt onder onverwachte belasting, faalt alles wat erdoorheen wordt gerouteerd meteen tegelijk in plaats van geleidelijk te verslechteren.
Een verkeerd geconfigureerde alert betekende dat niemand het aan zag komen
Een intern monitoringbeleid was verkeerd geconfigureerd en waarschuwde GitHub's engineers niet toen de sidecar-proxy zijn concurrency-limiet naderde, dus de waarschuwing die een reactie had moeten triggeren voordat gebruikers iets merkten, ging simpelweg nooit af. Dat gat weegt net zo zwaar als de concurrency-limiet zelf: een capaciteitslimiet die vroeg wordt opgemerkt is een stille upgrade, een limiet die pas wordt opgemerkt nadat gebruikers fouten zien wordt een incident van meerdere uren. GitHub zegt dat het dichten van dat monitoringgat deel uitmaakt van het "work ahead" waarnaar de titel van de postmortem verwijst.
GitHub's eigen retry-logica, vooral vanuit VS Code, maakte het erger
Optimistische client-side retry-logica in het hele GitHub-ecosysteem veranderde een overbelaste proxy in een platformbrede cascade, en GitHub wees een retry-storm vanuit VS Code-clients specifiek aan als een belangrijke factor in hoe erg de storing werd. Wanneer een verzoek mislukt en een client meteen opnieuw probeert zonder te wachten, mislukt het niet alleen opnieuw, het voegt nog een verzoek toe aan een al overbelast systeem, en vermenigvuldigd over miljoenen VS Code-installaties die op de achtergrond bij GitHub aankloppen, veranderde dat patroon een beperkt proxyprobleem in een platformbreed probleem. Dit is het detail dat van het incident geen verhaal over GitHub's infrastructuur maakt, maar een verhaal over hoe elke client van elke API zou moeten worden gebouwd.
Voor elk bedrijf dat zijn pipeline via GitHub laat lopen, was dit een black-out van 8 uur
De meeste bedrijven zien een GitHub-storing als een ongemak voor developers, iets om over te mopperen tijdens het wachten, maar voor elk bedrijf dat GitHub Actions en Copilot stilletjes in zijn releasepipeline heeft ingebouwd, zijn 7 uur en 47 minuten zonder GitHub 7 uur en 47 minuten waarin je geen hotfix kunt uitrollen, geen beveiligingspatch kunt mergen en, als Copilot deel uitmaakt van de workflow, halverwege een taak een AI-codeertool kwijtraakt. Dat is een concentratierisico op één leverancier, verborgen binnen wat aanvoelt als "gewoon GitHub gebruiken", en het verschijnt op geen enkele budgetregel zoals een softwareabonnement dat wel zou doen. De scherpere les is de retry-storm: als GitHub's eigen clientsoftware een storing erger maakte door agressief opnieuw te proberen zonder te wachten, zou elk bedrijf dat zijn eigen systemen bouwt tegen API's van derden zijn eigen retry-logica moeten controleren op datzelfde faalpatroon, in plaats van dit puur als GitHub's probleem weg te zetten.
Lees hierna: Wiz' AI-Agent Hackte Snowflake en Beschuldigde Copilot | Uw Tweede Git-Host Schakelde Zichzelf In
