GitHub's storing: een verdubbelde commit-last

Zeven Uur En Zevenenveertig Minuten, Herleid Tot Een Overbelaste Proxy

GitHub's eigen rapport, gepubliceerd op de eigen engineeringblog onder de titel 'The August 17 outage, and the work ahead', herleidt de storing tot een Istio-sidecarproxy in het datacenter Central US die zijn maximale gelijktijdige verwerkingscapaciteit bereikte. Het autoscalingbeleid dat die capaciteit bewaakte, beoordeelde alleen de applicatiedienst zelf, niet de verbindings- en concurrencystatus van de sidecars die ervoor stonden, waardoor niets opschaalde toen de sidecars hun limiet bereikten. Toen die proxy's verzadigd raakten, verschoven aanvragen naar andere nodes, die op hun beurt hun eigen capaciteitsgrenzen bereikten, en GitHub's automatische retry-logica verergerde de spiraal door nieuwe aanvragen naar reeds overbelaste load balancers te sturen. Een aparte retry-bug, volgens The Register aanwezig in een VS Code-extensie voor GitHub Copilot-authenticatie, verergerde de storing verder: die bleef zonder pauze nieuwe authenticatietokens aanvragen, waardoor GitHub's tokendienst van een normale basis van 7.000 tot 9.000 aanvragen per seconde opliep naar 70.000 tot 100.000 aanvragen per seconde, ongeveer tien keer de gebruikelijke belasting.

De Cijfers Achter Een Slechte Middag

De storing liep op 17 augustus 2026 van 13:28 tot 21:15 UTC, en GitHub's eigen statusupdates plaatsten de piekfoutpercentages op ongeveer 20 procent voor web- en API-verkeer en circa 50 procent voor downloads van archieven en ruwe inhoud, precies het soort aanvraag waarvan een build-pipeline of een dependency-download afhankelijk is. Issues, pull requests, API's, Actions en Copilot waren allemaal aangetast, samen met SAML- en OIDC-authenticatie, SCIM en Team Sync; de meeste diensten herstelden rond 16:36 UTC, Actions rond 18:03 UTC, en de Copilot-tokendienst als laatste, om 21:02 UTC. GitHub maakte expliciet duidelijk dat noch dit incident, noch de kleinere Actions-storing van 6 augustus veroorzaakt werd door een code- of configuratiewijziging; beide waren, in de eigen woorden van het bedrijf, in de kern capaciteitsstoringen, wat betekent dat het systeem zonder marge kwam te zitten in plaats van te breken door een verzonden fout.

Het Aantal Commits Verdubbelde Bijna In Vier Maanden

Verscholen in datzelfde rapport staat het cijfer dat dit verhaal van een storing verandert in een verhaal over infrastructuur: GitHub stelt dat het maandelijkse aantal commits sinds april 2026 steeg van 1,4 naar 2,9 miljard, in ongeveer vier maanden dus vrijwel verdubbeld, samen met grafieken die samengevoegde pull requests laten oplopen tot rond de 130 miljoen per maand en nieuwe repositories tot rond de 24 miljoen per maand. GitHub had de oorzaak al aangewezen in het beschikbaarheidsrapport van mei 2026, waarin het bedrijf erkende dat AI-ondersteund programmeren en agentische workflows extra druk op de infrastructuur legden, en Microsoft heeft publiekelijk verklaard dat AI inmiddels tot 30 procent van de code in sommige eigen repositories schrijft, onder voorbehoud van menselijke controle. Een platform dat gedimensioneerd was voor een wereld waarin commits binnenkwamen op het tempo van menselijk typen, absorbeert nu een belastingspatroon dat wordt bepaald door codeeragenten die continu schrijven, vertakken en pushen, en GitHub's reactie tot nu toe bestond uit meer capaciteit: meer dan 3 miljoen CPU-cores en 120 petabyte aan snelle opslag, waarbij Azure inmiddels ongeveer 58 procent van de platformbelasting draagt, tegenover 12 procent in mei.

GitHub Actions Registreerde Dertien Incidenten In Zeventien Dagen

Tech Times analyseerde GitHub's incidentgeschiedenis en statusgegevens en meldde dat GitHub Actions alleen al 13 aparte incidenten registreerde binnen een periode van 17 dagen deze augustus, en dat de beschikbaarheid over 90 dagen daalde van 99,39 procent voor de storing van 17 augustus naar 99,33 procent erna, een daling van ongeveer 13 uur opgebouwde downtime in drie maanden naar ongeveer 14,5 uur. Dat medium stelde dat het incident van 17 augustus alleen al bijna een heel jaarbudget aan toegestane downtime had opgesoupeerd tegenover een drie-negens-doel. GitHub's eigen rapport telt anders en noemt 17 augustus zijn tweede significante incident van de maand, na de Actions-storing van 6 augustus, wat een eerlijke telling is van grote, platformbrede storingen, maar niets zegt over de kleinere, frequentere Actions-verstoringen daaronder. Beide tellingen kunnen tegelijk waar zijn, en samen beschrijven ze een tweeledig betrouwbaarheidsprobleem: de kern-Git-dienst houdt beter stand dan de CI/CD-pipeline die erbovenop is gebouwd, en precies die pipeline draagt het grootste deel van de nieuwe belasting van AI-ondersteunde ontwikkeling.

Een Platform, Elke Pipeline: Het Concentratierisico

Voor een bedrijf dat zijn hele engineeringworkflow via GitHub laat lopen, dus versiebeheer, CI via Actions, het eigen pakketregister en Copilot voor codegeneratie, is niets daarvan achtergrondruis; het is een enkele leverancier op het kritieke pad van elke release. Een Europees ontwikkelteam voelt dit tijdens het storingsvenster zelf net zo als een Amerikaans team, maar draagt daarbovenop een extra laag blootstelling: contractuele leverdata, SLA-toezeggingen aan EU-klanten en meldplichten bij incidenten onder kaders zoals NIS2 pauzeren niet omdat de storing ontstond in een Amerikaans datacenter buiten de controle van het team. 'GitHub is down' behandelen als achtergrondruis houdt op zinvol te zijn zodra de onderliggende cijfers laten zien waarom het gebeurde: infrastructuur gebouwd voor een langzamere, menselijk getakte wereld absorbeert nu een belastingspatroon dat in vier maanden bijna verdubbelde, op een platform dat, naar eigen zeggen, augustus doorbracht met het twee keer oplossen van dezelfde categorie capaciteitsstoring.

Hoe Redundantie Er In De Praktijk Uitziet

Niets van dit alles pleit ervoor om GitHub te verlaten, dat om goede redenen de standaardkeuze blijft, maar het is een concreet argument om afhankelijkheid van een leverancier te behandelen als een gepland risico in plaats van een achteraf ontdekte bijgedachte midden in een storing. Dat betekent een gespiegelde kopie van kritieke repositories op een tweede host of een zelf gehoste Git-server, een alternatieve CI-runnerconfiguratie die builds kan overnemen wanneer Actions is aangetast en niet pas wanneer het volledig uitvalt, en een lokale of zelf gehoste cache voor pakketafhankelijkheden, zodat een storing van het register niet elke build in de pipeline stopt. Geen van deze maatregelen hoeft continu te draaien; ze moeten bestaan, af en toe getest worden en goed genoeg gedocumenteerd zijn zodat een team onder druk tijdens het volgende incident niet voor het eerst improviseert terwijl de klok van een klantdeadline blijft doortikken.

Lees hierna: Uw Tweede Git-Host Schakelde Zichzelf In  |  Ierland schrapt zijn Microsoft-contract