We kunnen niet met één GitHub

Op 17 augustus lag GitHub bijna acht uur plat. Eén middag, en daarmee was zo ongeveer het hele jaarbudget aan toegestane downtime op. Ik zat die middag naar een pipeline te kijken die nergens heen ging en dacht: dit is niet de eerste keer dit jaar.
Even vooraf, want dit is een zeepkist en geen productvergelijking. Wij gebruiken GitHub én GitLab, elke dag, bij klanten en bij onszelf. Ik heb geen kamp. Wat ik wél had was een ongemakkelijk gevoel, en toen ik de cijfers erbij zocht bleek het geen gevoel te zijn.
De cijfers
Tussen mei 2025 en april 2026 telde GitHub 257 incidenten, waarvan 48 grote storingen. Februari 2026 was met 37 incidenten de slechtste maand. De drie negens — 99,9 procent — die Enterprise-klanten contractueel beloofd krijgen, zijn in die periode niet gehaald.
Maar het interessantste getal is een ander: 83 van die 257 incidenten kwamen door capaciteit en belasting. Veruit de grootste enkele oorzaak. Dit is dus geen platform dat struikelt over een slechte migratie of een kapotte deploy. Dit is een platform dat meer werk binnenkrijgt dan het aankan.

GitHub's incidenten tussen mei 2025 en april 2026: 83 van de 257 kwamen door capaciteit en belasting, veruit de grootste enkele oorzaak. GitLab rapporteert een andere maatstaf — maandbeschikbaarheid — en kwam daar op 99,98 en 100 procent.
Eerlijk is eerlijk: meer gemelde incidenten kan ook méér transparantie betekenen. Een leverancier die alles publiceert ziet er slechter uit dan eentje die zwijgt. Maar deze rapporten komen van GitHub zelf, en ze zijn niet vrolijk.
Waarom uitgerekend nu
Dat capaciteitsgetal is geen toeval, het is een symptoom van het jaar waarin we zitten. Een team van tien mensen pushte vroeger een stuk of dertig keer per dag. Datzelfde team met agents erbij opent pull requests, draait pipelines, doet reviews en herstart builds in een tempo waar geen enkele capaciteitsplanning van vijf jaar geleden op gebouwd is.
Het gevolg is wrang. Juist nu je platform het meest moet kunnen hebben, is het de bottleneck. Je agents staan te wachten op een runner. Het duurste onderdeel van je toolchain is niet meer het model — het is de wachtrij ervoor. Wat dat wachten een engineer per dag kost, rekenden we eerder uit.
En toen was het een divisie
In augustus 2025 vertrok Thomas Dohmke als CEO van GitHub. Er kwam geen opvolger. De leiding rapporteert sindsdien rechtstreeks aan Microsofts CoreAI-team onder Jay Parikh. Na bijna zeven jaar als zelfstandig opererend onderdeel is GitHub nu letterlijk een divisie.
Dat is geen onderbuikgevoel en geen sfeerbeeld. Dat is het organogram.
Het omgekeerde Midas-syndroom
Ik roep al jaren dat Microsoft aan het omgekeerde Midas-syndroom lijdt: alles wat ze aanraken en met internet te maken heeft, verandert in stront. Het is een grap, maar het lijstje eronder is dat niet.
Skype: 8,5 miljard dollar in 2011, op 5 mei 2025 uitgezet na 22 jaar. aQuantive: 6,3 miljard in 2007 om Google's advertentiepositie aan te vallen, in 2012 vrijwel volledig afgeschreven. Nokia: 7,2 miljard gekocht, 7,6 miljard afgeschreven — de grootste afschrijving die Microsoft ooit nam, plus 18.000 ontslagen.
En dan Yahoo, wat mij betreft de mooiste, want die is juist ontsnapt. Microsoft bood in februari 2008 44,6 miljard dollar. Yahoo's bestuur vond dat het bod het bedrijf onderwaardeerde en wees het unaniem af; Microsoft trok zich in mei terug. Acht jaar later ging de kernactiviteit voor zo'n 4,5 miljard van de hand. Blijkbaar hoef je de aanraking niet eens te ondergaan.
Maar hier moet ik mezelf corrigeren, en dat doe ik graag: bij GitHub is het ze zeven jaar lang níet overkomen. Zeven jaar waarin GitHub gewoon GitHub bleef, met een eigen CEO, een eigen cultuur en een productrichting die niet uit Redmond kwam. Dat is de langste remissie in het hele lijstje. Het bewijst dat het kán. En precies daarom is het nieuws van vorig jaar zo vervelend.
Bitbucket is de waarschuwing, niet de grap
Wie denkt dat dit alleen over Microsoft gaat, moet naar Bitbucket kijken. Atlassian kocht het in 2010 en ik was destijds oprecht enthousiast. De overstap van Bamboo naar Bitbucket was een verademing, en Bitbucket Pipelines had als een van de eersten een CI die volledig op Docker-images draaide: je hele build-omgeving werd één regel in een yaml-bestand. Dat was, in die jaren, echt vooruit.
Het kantelpunt kwam in augustus 2019, met de aankondiging dat Mercurial eruit ging. Op 1 juni 2020 waren die repository's weg. Bitbucket wás de Mercurial-host — daar kwam het vandaan, dat was zijn onderscheid. Dat is geen productbeslissing, dat is je eigen bestaansreden opruimen omdat hij niet meer in het kwartaalplan past.
Wat daarna kwam is een langzame afbraak die iedereen die er wel eens inlogt herkent. Ik ga er hier niet over uitweiden, want dan wordt dit een ander artikel. Kort samengevat: voor Bitbucket vrezen wij dat hulp te laat komt.
Ondertussen stapelt GitLab
En dan GitLab, dat al jaren hetzelfde saaie kunstje doet: leveren. Source control, CI/CD, security scanning, registry en planning zitten in één product in plaats van in een marktplaats vol integraties die je zelf aan elkaar knoopt. Op beschikbaarheid rapporteerde GitLab 99,98 procent in november 2025 en 100 procent in augustus en september. Beide leveranciers beloven 99,9. Er is er één die het haalt. Welke van de twee bij een organisatie past is een vraag op zich, en precies het soort vraag waar onze tech-consultancy voor bestaat.
Voordat iemand denkt dat ik nu GitLab-fanboy ben: GitLab is een beursgenoteerd bedrijf waarvoor in juli 2024 en opnieuw in oktober 2025 overnameinteresse van Datadog is gemeld. Onbevestigd, en analisten waren sceptisch, dus neem het als ruis. Maar de zelfstandigheid van GitLab is een marktvraag, geen natuurwet. Wie vandaag bij GitHub wegloopt omdat het een divisie werd, kan over twee jaar hetzelfde meemaken.
Wat wij ervan vinden
Wij oordelen niet en wij kiezen niet. Bij ZEN draaien klanten op GitLab en op GitHub, en dat blijft zo; wij bouwen de ontwikkelstraat eromheen, niet de leverancierskeuze. Wat wij wél vinden: één grote leverancier van source control en CI is geen markt. Dat is een single point of failure met een verkoopafdeling.
Er moeten er minstens twee zijn. Niet omdat concurrentie een deugd op zichzelf is, maar omdat de dag waarop er één omvalt — voor acht uur, of voor altijd — geen dag mag zijn waarop de halve industrie stilstaat. Zo'n dag is trouwens geen abstractie: hij landt rechtstreeks in je DORA-cijfers. Wij hebben er zakelijk niets aan als GitHub wint, en net zo min als GitLab wint.
Dus: GitHub, los het op. Die capaciteit is een oplosbaar probleem en je hebt de rijkste moeder ter wereld. We hebben je nodig. GitLab, blijf doen wat je doet. En Bitbucket — het spijt me oprecht, want je was ooit het leukste van de drie.

CI/CD veilig en snel in de cloud
ZEN Software biedt gestandardiseerde ontwikkelstraten in de cloud voor supersnelle software delivery, geautomatiseerde tests en security scans.
Lees ook:

We kunnen niet met één GitHub
Bijna acht uur plat op één middag, 48 grote storingen in een jaar, en de grootste oorzaak is capaciteit. Over GitHub dat...

Wat dertig minuten wachten per engineer per dag echt kost
Een half uur per dag. Zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljo...

Wat je mist is meestal geen gereedschap
Ik ging die podcast in met een boodschappenlijstje: welke tools mis ik. Ik kwam eruit met drie dingen die je geen van al...

Zenthropic: AI-telefoonagenten die 24/7 opnemen
De telefoon gaat buiten kantooruren, tijdens een incident, of precies als iedereen in een overleg zit. Zenthropic zet da...

DORA-metrics lezen als AI de helft van je commits schrijft
Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde. Zodra een flink deel...

De bedenker van Ruby on Rails schrijft geen regel code meer zelf
De bedenker van Ruby on Rails schrijft geen regel code meer zelf en stuurt zestien agents tegelijk aan. Vijf uur gesprek...
