Update 25 september 2026Op 17 augustus 2026 lag GitHub 7 uur en 47 minuten grotendeels plat, volgens GitHub door een capaciteitstekort; het aantal commits per maand verdubbelde sinds april van 1,4 naar 2,9 miljard en Azure draagt nu zo’n 58% van de platformbelasting (GitHub). Over AWS zegt GitHub daarin niets. We hebben ook het beschikbaarheidscijfer en de beschrijving van het incident van 27 april gecorrigeerd.
Stand van zaken 18 juni 2026Dit speelt nú. De cijfers over storingen en capaciteit komen uit GitHubs eigen blog en onafhankelijke analyse; het bericht dat Microsoft uitwijkt naar Amazon is door techmedia gemeld maar niet officieel bevestigd. We zetten beide netjes uit elkaar.
Het grootste codeplatform ter wereld hapert al maanden
AI schrijft inmiddels zoveel code dat het platform waar die code belandt, het niet bijhoudt. GitHub, de grootste opslagplaats voor software ter wereld en eigendom van Microsoft, kampt sinds begin 2026 met aanhoudende storingen. Een onafhankelijke tracker zette de beschikbaarheid in april 2026 op rond de 86%: omgerekend ruim drie uur per dag waarop ergens een deel van het platform niet werkte (Bron: The Pragmatic Engineer).
De oorzaak die GitHub zelf aanwijst: een stortvloed aan AI-codeeragents. En dat maakt dit meer dan een technisch verhaal voor programmeurs. Het is een van de eerste keren dat de AI-hype zichtbaar tegen een muur loopt — de infrastructuur eronder.
Beginner-tipGitHub is de plek waar softwaremakers hun code bewaren en samen aanpassen, een soort gedeelde Google Drive voor programmeurs. Een AI-codeeragent is een programma dat zelfstandig code schrijft en die wijzigingen indient, zonder dat een mens elke regel typt. Hoe meer van die agents, hoe meer verkeer richting GitHub.
Wat er aan de hand is
In een uitzonderlijk openhartige blogpost legde GitHub-CTO Vlad Fedorov de vinger op de wond. Sinds de tweede helft van december 2025 versnelden “agentic” ontwikkelworkflows scherp: het aanmaken van repository’s, pull requests, API-verkeer en automatisering groeide allemaal hard tegelijk (Bron: GitHub Blog). Het bedrijf begon in oktober 2025 aan een plan om de capaciteit te vertienvoudigen. Tegen februari 2026 was duidelijk dat dat niet genoeg was: men moest gaan ontwerpen voor dertig keer de huidige schaal.
Het probleem zit ‘m niet in één systeem. Eén pull request raakt opslag, controles, GitHub Actions, zoekfunctie, notificaties, rechten, webhooks, API’s en databases tegelijk. Bij hoge belasting stapelen kleine inefficiënties zich op: wachtrijen lopen vol, een trage schakel sleept meerdere onderdelen mee. Precies dat gebeurde.
Hoe erg het is
Twee incidenten in april tekenen het beeld. Op 23 april ging het mis bij het samenvoegen van code: door een fout raakten commits in 2.092 pull requests in de war, waarbij eerder samengevoegd werk per ongeluk werd teruggedraaid. Getroffen bedrijven moesten handmatig hun codegeschiedenis uitpluizen om verloren werk terug te halen. Vier dagen later, op 27 april, raakte het zoeksysteem overbelast (volgens GitHub vermoedelijk door een botnetaanval), waardoor pull requests en issues in delen van de site simpelweg uit beeld verdwenen (Bron: GitHub Blog).
De onvrede werd persoonlijk. Mitchell Hashimoto, oprichter van HashiCorp en maker van de populaire terminal Ghostty, kondigde na achttien jaar zijn vertrek van GitHub aan. Zijn reden was simpel: hij hield een logboek bij en zette bijna elke dag een kruisje bij een storing die zijn werk blokkeerde. “Dit is geen plek meer voor serieus werk als het je elke dag urenlang buitensluit”, schreef hij.
Draait GitHub nu op Amazon?
Hier is voorzichtigheid op zijn plaats. Verschillende techmedia meldden rond 16 juni dat Microsoft een deel van GitHubs werk verschuift naar Amazon Web Services, de grootste cloudrivaal van Microsoft, om de pieken op te vangen (Bron: TechTimes). Microsoft en GitHub hebben dat niet officieel bevestigd.
Wat GitHub zélf zegt, is iets terughoudender maar in dezelfde richting: het zit middenin een verhuizing naar Microsofts eigen Azure-cloud, en werkt aan een stap richting “multi-cloud” — meerdere cloudleveranciers tegelijk gebruiken voor meer veerkracht. Dat een bedrijf van Microsoft daarvoor zou aankloppen bij aartsrivaal Amazon is opvallend genoeg om met bronvermelding te melden, maar tot een officiële bevestiging er is, houden we het bij: gerapporteerd, nog niet bevestigd.
De nuance: is het wel een AI-tsunami?
Het makkelijke verhaal is “AI brak het internet”. De werkelijkheid is rommeliger, en juist daarom interessanter. Gergely Orosz, een in Amsterdam gevestigde software-analist, kreeg de onderliggende cijfers boven tafel. GitHubs eigen grafieken oogden dramatisch, maar misten een verticale as. De feitelijke groei in belasting? Ongeveer 3,5 keer in twee jaar (Bron: The Pragmatic Engineer). Fors, maar geen tienvoud in een maand.
En dan wringt het. Andere diensten die net zo hard groeien door AI — Vercel, Linear, en directe concurrenten GitLab en Bitbucket — lijken de belasting beter bij te houden. Een deel van GitHubs pijn lijkt dus zelf veroorzaakt: een verhuizing die laat op gang kwam, systemen die vaak al meer dan tien jaar oud zijn, en een organisatie van vierduizend man die niet zo wendbaar is als een start-up. AI was de vonk, maar het droge hout lag er al.
Wat dit betekent
Voor jou als consument verandert er morgen weinig zichtbaars; je opent GitHub vermoedelijk nooit. Toch raakt het je indirect, want de software achter je bank-app, je webshop en je favoriete diensten wordt grotendeels op deze infrastructuur gebouwd. Hapert de fundering, dan voelen de huizen erbovenop dat vroeg of laat.
De bredere les is de moeite waard. We praten veel over wat AI kán maken, en weinig over waar al dat gemaakte spul landt. Een model dat in seconden code, tekst of beeld uitspuugt, verschuift de druk naar de systemen eronder: opslag, rekenkracht, controle. GitHub is het eerste grote platform dat openlijk kraakt onder dat gewicht. Het zal niet het laatste zijn. Diezelfde spanning zagen we al bij de torenhoge rekening die AI-bedrijven voor pure rekenkracht betalen, en bij de overstap van Copilot naar afrekenen per gebruik. De tools worden goedkoper en sneller; de fundering eronder juist duurder en zwaarder belast.