GitHub-storing van 17 augustus trof downloads, Actions en Copilot: dit weten we

In een update van 12.36 uur EDT zei GitHub dat het betreffende onderdeel was geïdentificeerd en dat het platform duidelijke tekenen van herstel vertoonde. De dienstverlening was op dat moment echter nog niet volledig stabiel.

Het herstel verliep niet overal tegelijk. Belangrijke diensten kwamen weer beschikbaar, terwijl Copilot in sommige toepassingen nog te maken had met authenticatieproblemen. Volgens andere incidentoverzichten eindigde de totale verstoring rond 21.15 uur UTC. Daarmee duurde het volledige incident aanzienlijk langer dan de eerste fase met de zwaarste degradatie.

Hoe groot was de impact?

De duidelijkste cijfers komen uit de foutpercentages die GitHub zelf rapporteerde:

• Webervaring en API-verkeer: ongeveer 20% fouten.
• Archiefdownloads en ruwe repository-inhoud: ongeveer 50% fouten.
• Ontwikkelaarsdiensten: Pull Requests, Issues, Actions, Webhooks, Git-operaties en Pages waren op verschillende momenten vertraagd, beperkt beschikbaar of niet bereikbaar.
• AI-ondersteuning voor programmeren: GitHub Copilot werd getroffen en bleef ook na het herstel van meerdere kerndiensten een actief probleem.
• Enterprise-identiteit: meldingen wezen op problemen met SAML- en OIDC-authenticatie, SCIM-provisioning en Team Sync. Organisaties konden daardoor mogelijk niet betrouwbaar gebruikers aanmelden of toegangsrechten beheren.

Deze percentages zeggen niet welk deel van alle GitHub-gebruikers offline was. Een foutpercentage van 20% voor API-aanvragen betekent niet dat precies 20% van de klanten geen toegang had. Ook de 50% voor downloads geldt voor de getroffen downloadaanvragen, niet voor al het repositoryverkeer.

Waarom een storing op maandagochtend extra hard aankomt

De problemen begonnen op een maandagochtend in de Verenigde Staten, aan het begin van de werkweek voor veel engineeringteams. Dat tijdstip is relevant: het openen van broncode, code reviews, continuous integration en deploymentautomatisering horen vaak bij de eerste werkstroom van de dag. Actions, Pull Requests, API’s en Webhooks behoorden tot de getroffen diensten. Teams konden daardoor fouten tegenkomen in meerdere opeenvolgende stappen, in plaats van in één losstaande functie.

Ook het aantal meldingen bij storingssites verschilde per moment en meetmethode. Eén bericht sprak van meer dan 10.000 meldingen bij Downdetector rond 8.12 uur Pacific Time, terwijl een ander herstelbericht een piek van bijna 3.000 meldingen noemde. Zulke aantallen zijn geen exacte telling van getroffen gebruikers: storingssites tellen ingezonden meldingen, en de uitkomst hangt af van onder meer regio, tijdstip en meetmethode.

Wat GitHub deed — en wat nog niet is uitgelegd

De openbare updates van GitHub maken drie onderdelen van de reactie duidelijk:

1. Ingenieurs onderzochten verhoogde foutpercentages en prestatieproblemen in meerdere diensten.
2. Het bedrijf identificeerde een problematisch onderdeel en nam corrigerende maatregelen.
3. GitHub bleef mitigaties uitvoeren nadat de belangrijkste platformdiensten begonnen te herstellen, onder meer om sporadische authenticatiefouten bij Copilot in sommige toepassingen op te lossen.

De beschikbare informatie noemt niet welk onderdeel precies betrokken was, welke corrigerende actie is uitgevoerd of dat capaciteitsdruk de oorzaak van dit specifieke incident was. GitHub heeft wel in bredere betrouwbaarheidsupdates geschreven over de groei van AI-ondersteunde en agentische ontwikkelworkflows en over beperkingen in de infrastructuur. Dat maakt AI-belasting of capaciteitsproblemen echter nog niet tot een bevestigde oorzaak van de storing van 17 augustus.

Een nieuw incident in een lastig jaar voor GitHub

De augustusstoring volgde op een periode met meerdere betrouwbaarheidsproblemen. In het beschikbaarheidsrapport van juli documenteerde GitHub acht incidenten. Eén incident op 8 juli duurde meer dan zeven uur en raakte in sommige Enterprise Cloud-omgevingen onder meer de webinterface, REST- en GraphQL-API’s, Actions, Packages, Copilot en Git-operaties.

GitHub heeft daarnaast een bredere infrastructuuropgave beschreven. Volgens het bedrijf groeit het verkeer snel, voor een belangrijk deel door AI-ondersteunde en agentische ontwikkelworkflows. Genoemde maatregelen zijn het onderbrengen van meer capaciteit in Azure, het opsplitsen van diensten en het verminderen van gedeelde afhankelijkheden die storingen kunnen laten escaleren.

De omvang van de geplande opschaling is opvallend. GitHub mikte aanvankelijk op een capaciteitsvergroting van tien keer, maar stelde later vast dat het systeem moest worden ontworpen voor 30 keer de toenmalige schaal. Andere berichtgeving beschreef naast Azure ook extra capaciteit via een multicloudaanpak, waaronder AWS. Die plannen verklaren op zichzelf niet waarom de storing in augustus ontstond.

De betekenis van het incident reikt daardoor verder dan één slechte ochtend. GitHub is niet alleen een plek om Git-repository’s op te slaan, maar ook een samenwerkingslaag, automatiseringsplatform, identiteitsvoorziening en AI-dienst voor programmeurs. Als gedeelde afhankelijkheden uitvallen, kunnen repositorytoegang, reviews, builds, deployments, Webhooks en AI-assistentie tegelijk worden verstoord.

Wat organisaties hiervan kunnen leren

De storing bewijst niet dat ontwikkelaars GitHub massaal zullen verlaten. Evenmin biedt de beschikbare informatie basis voor de voorspelling dat er op korte termijn een grote migratiegolf ontstaat. Wel laat het incident zien waarom organisaties die voor productie-uitrol op GitHub vertrouwen hun aannames over uitval opnieuw moeten bekijken.

Praktische maatregelen zijn onder meer het bijhouden van repositoryback-ups of mirrors, het portable houden van CI/CD-configuraties, het documenteren van noodprocedures voor releases en het voorbereiden van teams op situaties waarin SSO, Webhooks of gehoste runners niet beschikbaar zijn. Zulke maatregelen nemen platformrisico niet weg, maar kunnen de reikwijdte van een volgende storing beperken.

Het definitieve oordeel over 17 augustus hangt af van GitHubs postmortem. Tot die analyse verschijnt, is de meest verdedigbare conclusie beperkter: GitHub kreeg te maken met een brede, zich uitbreidende serviceverstoring die vooral repositorydownloads en gekoppelde ontwikkelworkflows zwaar raakte. Het herstel verliep gefaseerd en de onderliggende fout is publiekelijk nog niet verklaard.