GitHubs crisis van april 2026: wat 30x schaal onthult

GitHubs crisis van april 2026: wat 30x schaal onthult

Ik heb de lijst met pull-aanvragen voor de derde keer vernieuwd. Leeg. De repository had die ochtend veertien geopende PR's (ik had er twee voor de lunch besproken) en nu liet de pagina me het soort schone lei zien dat je alleen op een gloednieuwe repository ziet. Mijn eerste gedachte was niet: "GitHub is offline." Mijn eerste gedachte was: "Heeft iemand van het team alles massaal afgesloten terwijl ik aan het bellen was?"

Toen opende ik de terminal. gh pr list. Alle 14 PR's. Precies daar. Nummers, titels, auteurs, conceptstatussen. Onaangeroerd.

Die kloof – de gegevens bestaan, maar de gebruikersinterface kan deze niet zien – is de hele vorm van de GitHub-beschikbaarheidscrisis van april 2026 die de ontwikkelaarsgemeenschap heeft overhandigd. Het is niet het soort storing waarbij het platform omvalt en een statuspagina rood wordt. Het is erger. Het is het soort waarbij alles er kapot uitziet op een manier die je doet twijfelen aan je eigen werk, terwijl de onderliggende systemen stilletjes volhouden dat alles in orde is.

Tegen het einde van de week zag ik binnen zeven dagen twee verschillende foutmodi op hetzelfde platform terechtkomen, las ik de update van GitHub CTO drie keer en begon ik opnieuw na te denken over hoe ik alles ontwerp dat in aanraking komt met API van GitHub. Omdat het verhaal hieronder niet echt over twee bugs gaat. Het gaat over wat er gebeurt als het knelpunt voor de wereldwijde softwareontwikkeling wordt getroffen door een belastingscurve waarvoor niemands infrastructuur is ontworpen - en de agentic AI-tools die jij en ik elke dag gebruiken, zijn een deel van waarom.

De week waarin de gebruikersinterface van GitHub begon te liegen tegen ontwikkelaars

Laat ik de scène goed schetsen, want de volgorde van de gebeurtenissen is belangrijk.

Het eerste teken dat er structureel iets mis was, kwam op 31 maart 2026, toen GitHub een zogenaamde "echte" storing had: ongeveer zes uur verminderde beschikbaarheid als gevolg van gegevensverlies op interne systemen. Pijnlijk, veelbesproken, en het soort dingen waar elk technisch team een ​​paar keer per decennium mee te maken krijgt. Ik heb het als eenmalig beschouwd.

Toen gebeurde 23 april. Corruptie van wachtrijen samenvoegen. Pull-aanvragen die in de wachtrij kwamen, kwamen er niet altijd netjes uit aan de andere kant. Sommige teams slaagden erin, andere niet. Als je nog nooit afhankelijk bent geweest van samenvoegwachtrijen in een monorepo met hoge snelheid, is dit het soort bug dat stilletjes het vertrouwen in de hele automatiseringslaag ondermijnt: je CI zegt groen, de samenvoeging zegt samengevoegd, en dan merkt iemand dat de daadwerkelijke commit niet op de juiste manier terecht is gekomen.

27 april was het moment waarop het luid werd. De lijstweergaven met pull-aanvragen begonnen lege of gedeeltelijke resultaten op te leveren. Het zoeken naar problemen is mislukt. Projectbordfilters zijn gestopt met oplossen. De eerste berichten die ik op sociale media zag, waren mensen die hun collega's ervan beschuldigden werk te verwijderen, wat precies de verkeerde conclusie is, maar wel een heel menselijke. Het kostte het incidentkanaal van GitHub een paar uur om de daadwerkelijke oorzaak te bevestigen: het cluster ElasticSearch dat door zoekopdrachten ondersteunde weergaven mogelijk maakte, was overweldigd, naar verluidt onder invloed van botnets, en gaf geen bruikbare resultaten meer terwijl het probeerde te herstellen.

Geen gegevensverlies. Core Git-bewerkingen werkten de hele tijd. De API bleef correcte resultaten retourneren aan iedereen die wist de webinterface te omzeilen en rechtstreeks te vragen. Maar voor de miljoenen ontwikkelaars die GitHub voornamelijk via github.com/org/repo/pulls ervaren, had het platform net zo goed plat kunnen liggen.

Dat is het deel waar ik steeds naar terug bleef cirkelen. De gegevens waren er altijd. De infrastructuur die de gegevens vindt heeft gefaald. En dat onderscheid is precies waar het interessant wordt.

Waarom "GitHub is down" het verkeerde mentale model is

Als je GitHub als één grote monolithische dienst behandelt, zien de incidenten van april 2026 er willekeurig uit. Zes uur hier, een storing in de samenvoegwachtrij daar, een zoekstoring vier dagen later. Van binnenuit is het niets dergelijks: het is een specifieke klasse van faalmodi die herhaaldelijk op een specifieke plek in de architectuur verschijnt.

Hier is het mentale model dat mij heeft geholpen het te begrijpen.

Moderne GitHub bestaat uit minimaal drie services die op elkaar zijn gestackd:

1. De Git-laag — daadwerkelijke opslag in de repository, push/pull, vertakken, samenvoegen. Dit is het deel dat niemand zich kan veroorloven kapot te gaan, en het deel dat het beste stand heeft gehouden.
2. De metadata- en workflowlaag — pull requests, problemen, projecten, acties, webhooks, machtigingen. Dit is grotendeels het Ruby-monolietgebied, met daaronder MySQL en PostgreSQL.
3. De zoek- en ontdekkingslaag — ElasticSearch, indexeringspijplijnen, de lijstweergaven en filters waarop u daadwerkelijk klikt.

Toen het incident van 27 april plaatsvond, werd laag 1 niet verwijderd. Het grootste deel van laag 2 werd niet verwijderd. Het verwijderde laag 3 - en omdat laag 3 de gebruikersinterface is die de meeste ontwikkelaars gebruiken om hun werk te vinden, was de waargenomen explosieradius enorm, terwijl de daadwerkelijke functionele explosieradius beperkt bleef.

De bug in de samenvoegwachtrij van 23 april zat in laag 2. Het gegevensverlies van 31 maart was dieper, dichter bij de grens tussen laag 1 en laag 2. Drie verschillende fouten, drie verschillende lagen, allemaal binnen vier weken. Dat is geen pech. Dat is een belastingscurve die op meerdere plaatsen tegelijk de architectuur overtreft.

En het is het tweede deel – de belastingscurve – waar ik de rest van dit bericht aan wil besteden. Omdat GitHub's CTO post-mortem in wezen het voor de hand liggende toegeeft: er wordt van het platform gevraagd iets te doen waarvoor het niet is gebouwd, en datgene wat dat vraagt, zijn deels wij.

Het 30x-getal dat elke engineer zou moeten laten stoppen

Hier is de zin van het leiderschap van GitHub die ik blijf herlezen. In oktober 2025 lanceerde het team een ​​capaciteitsuitbreidingsplan dat gericht was op een groei van 10x – een getal dat je voor elk infrastructuurteam als conservatief-agressief zou beschouwen. In februari 2026, vier maanden later, bleek uit interne modellen dat het werkelijke doel 30x was.

Lees dat nog eens. Niet 10x iets naar boven bijgesteld. Niet 12x of 15x. Verdrievoudig het oorspronkelijke doel, na slechts een paar maanden nieuwe gegevens.

De openbare update van GitHub noemt pieken van 90 miljoen samengevoegde pull requests, 1,4 miljard commits en 20 miljoen nieuwe repositories per maand. Zelfs één van die cijfers op zichzelf zou een flex zijn. Alle drie samen beschrijven ze een platform waarvan het laadprofiel in realtime wordt herschreven.

Wat is er veranderd tussen oktober en februari? Twee dingen, en ze houden verband.

De eerste ligt voor de hand: agentische ontwikkelingsworkflows gingen van nieuwigheid naar productie. Ik heb deze curve vanuit mijn eigen werk bekeken. In het derde kwartaal van 2025 waren agenten experimenteel: Claude Code was nieuw, de Anthropic Agent SDK was net geland en de meeste teams draaiden een of twee geautomatiseerde workflows in productie met veel menselijke beoordeling. In het eerste kwartaal van 2026 hadden dezelfde teams een vloot agenten. PR-agenten maken. Testfixatiemiddelen. Agenten die afhankelijkheid tegengaan. Documentatieagenten die samenvoegingen bewaakten en documenten automatisch bijwerkten.

Elk van deze agenten is een onvermoeibare, nooit slapende GitHub-gebruiker. Het opent PRs. Het pusht commits. Het leest problemen. Het raakt de API. Het activeert Action-runs. Waar een menselijke ontwikkelaar op een goede dag drie of vier PR's zou kunnen openen, zou een agent er dertig kunnen openen, en een vloot van agenten zou er duizenden kunnen openen in de hele organisatie.

De tweede verandering is structureel. Repository's zelf worden groter. Monorepo's komen vaker voor. AI-ondersteunde refactoren genereren grotere verschillen. Gegenereerde code (volledige applicaties geproduceerd door tools als Claude Code in één enkele prompt) produceert commits die honderden bestanden tegelijk betreffen. De eenheid van "verandering" op GitHub is gegroeid.

Vermenigvuldig deze twee trends met elkaar en je krijgt geen 10x groei. Je komt dichter bij een samengestelde exponentiële groei die elke zes tot acht maanden verdubbelt en geen tekenen van vertraging vertoont. Dat is precies wat het capaciteitsteam van GitHub heeft beschreven.

Als u zich heeft afgevraagd waarom uw CI dit jaar trager aanvoelt, waarom uw webhookvertragingen steeds groter worden, waarom uw gh CLI soms tien seconden blijft hangen voordat u een resultaat retourneert dat onmiddellijk zou moeten zijn: dit is uw antwoord. Je verbeeldt het je niet. Je voelt de belastingscurve.

Wat de ElasticSearch-storing ons feitelijk vertelt

Ik wil specifiek terugkomen op 27 april, omdat de fout in ElasticSearch het meest diagnostisch bruikbare incident van de drie is. Het vertelt ons iets specifieks over hoe een knelpunt van deze omvang faalt.

ElasticSearch met de grootte van GitHub is niet één cluster waar u meer knooppunten naartoe kunt gooien. Het is een strak afgestemd gedistribueerd systeem dat alles aanstuurt, van PR-lijstfilters tot het uitvoeren van zoekopdrachten, projectquery's en het ontdekken van repository's. Wanneer een botnet besluit er op in te gaan – en 'hameren' op GitHub-schaal betekent tienduizenden vervaardigde queries per seconde vanuit een gecompromitteerde infrastructuur - zie je niet alleen langzamere reacties. Je ziet dat indexeringspijplijnen achterop raken. Je ziet een ballon voor schrijfwachtrijen. Je ziet dat het cluster meer tijd besteedt aan het beheren van zijn eigen tegendruk dan aan het beantwoorden van echte vragen.

De oplossing bestaat uit het opnieuw opbouwen van indexen, het beperken van misbruik en het langzaam weer in gebruik nemen van het cluster. Niets daarvan is snel. Niets ervan is glamoureus. En de hele tijd dat dit gebeurt, ziet de rest van het platform er prima uit, terwijl een cruciale laag van de gebruikerservaring verslechtert.

Wat dit blootlegt – en wat GitHub nu publiekelijk heeft erkend – is dat het zoeksubsysteem een ​​single point of fail was dat nog niet was geïsoleerd van de rest van het platform. Het betrouwbaarheidswerk kreeg eerst elders prioriteit, op plaatsen die als een hoger risico werden beschouwd, en zoeken trok aan het kortste eind. Op 27 april leek het stellen van prioriteiten achteraf verkeerd, wat de wrede rekenkunde is van de respons op incidenten – elke autopsie is ook een kritiek op welke branden je besloot niet als eerste te bestrijden.

Hierin zit een les voor ontwikkelaars verborgen, en het is iets waar je gemakkelijk naar kunt knikken en moeilijk om daadwerkelijk te doen: de ontploffingsradius van je applicatie is niet hetzelfde als de voetafdruk van je applicatie. De gegevens van GitHub liepen op 27 april nooit gevaar. Hun kern Git-laag bleef neuriën. Maar omdat de meeste van hun gebruikers GitHub ervaren via een zoekgestuurde gebruikersinterface, werd een fout in de zoeklaag een gebeurtenis op platformniveau in ieders beleving. Wat kapot ging was niet het belangrijkste in hun architectuur. Het was het meest zichtbare ding.

Ik ben vorige week begonnen met het auditen van mijn eigen systemen met die lens. Welke subsystemen zouden, als ze falen, ervoor zorgen dat de rest van mijn applicatie er kapot uitziet, zelfs als dat niet het geval is? Het antwoord is ongemakkelijk. Het zijn er meer dan ik zou willen.

De CTO-routekaart, gedecodeerd

Het antwoord van GitHub op dit alles kwam in de vorm van een openbare update van de CTO, en ik wil er zorgvuldig doorheen lopen omdat de taal echt werk doet. Dit is niet alleen "het spijt ons, we zullen capaciteit toevoegen." Het is een gestructureerde erkenning van hoe de komende 12-24 maanden van GitHub-engineering eruit zullen zien - en de vorm ervan vertelt je iets over waar de hele industrie naartoe gaat.

De routekaart, zoals ik die lees, is onderverdeeld in vijf prioriteiten.

1. Beschikbaarheid gaat vóór capaciteit, capaciteit vóór functionaliteit. Dit is de herschikking in de kop. Gedurende het grootste deel van de geschiedenis van GitHub was de snelheid van functies de hoogste prioriteit: Copilot, Codespaces, Actions, Projects v2, agentische workflows, allemaal verzonden op agressieve tijdlijnen. De nieuwe bestelling is expliciet: laat eerst de lichten branden, zorg er dan voor dat de lichten bij 30x belasting kunnen blijven branden en verzend dan de nieuwe dingen. Iedereen die leiding geeft aan een infrastructuurteam heeft deze herschikking al eerder zien gebeuren, meestal na een slecht kwartaal. Het is de juiste beslissing. Het is ook een signaal dat het werk van sommige functies zichtbaar zal vertragen.

2. Verminder onnodig werk en verbeter caching. Dit klinkt saai totdat je je het PostgreSQL-voorbeeld herinnert dat GitHub gaf: snelheidsbeperking via niet-gelogde tabellen werkt prima bij minder dan 1.000 verzoeken per seconde, maar bij 10.000 RPS heb je Redis caching ervoor nodig, anders smelt de database. Elke laag van de stack heeft dergelijke drempels. Schalen is niet het toevoegen van hardware; het is het opmerken van elke plek waar een goedkoop patroon alleen werkte omdat de belasting laag was, en het opnieuw opbouwen ervan.

3. Isoleer kritieke diensten en beperk de straal van de ontploffing. Dit is wat 27 april had moeten voorkomen. Het werk hier is architectonisch: ervoor zorgen dat zoeken kan mislukken zonder PR-pagina's kapot te maken, ervoor zorgen dat de webhook-levering kan verslechteren zonder Actions te verwijderen, en ervoor zorgen dat tarieflimieten die op de ene tenant worden toegepast, niet in de andere overlopen. Elk 'isoleer X'-item op deze lijst is ook een erkenning dat X niet eerder geïsoleerd was.

4. Migreer prestatiegevoelige paden van de Ruby-monoliet naar Go. Dit is het meest tactische item en het meest geladen. De Ruby on Rails-monoliet is sinds het begin de identiteit van GitHub - er is een beroemde interne grap dat GitHub *de Rails-monoliet is met een aantal extra services eraan vastgeschroefd. Het verplaatsen van hot paths naar Go (en het verplaatsen van webhook-levering van MySQL naar alternatieve backends, wat ze ook noemden) is het soort werk dat jaren in beslag neemt en de manier verandert waarop ingenieurs over de codebase denken.

5. Azure-migratie en gereedheid voor meerdere clouds. Microsoft is eigenaar van GitHub, dus Azure-migratie zat er altijd aan te komen. Maar de multi-cloud-framing is nieuw en belangrijk: het suggereert dat het leiderschap van GitHub niet wil dat het regionale incident van een enkele cloudprovider het incident van GitHub wordt.

Als je deze routekaart leest en goed kijkt, is het hetzelfde draaiboek dat elk snelgroeiend platform van de afgelopen vijftien jaar heeft gebruikt. Twitter voerde het uit na het mislukte walvistijdperk. Stripe voert het continu uit. AWS voert het decennialang in slow motion uit. Het interessante is niet dat GitHub dit doet. Het interessante deel is de timing en de trigger.

Waarom Agentic AI-workflows de ontwikkelinfrastructuur hervormen

Dit is het deel dat het meest direct aansluit bij waar ik elke week over schrijf. De reden dat GitHub zijn groeidoelstelling in vier maanden moest herzien van 10x naar 30x is niet dat menselijke ontwikkelaars plotseling drie keer productiever worden. Het is dat de eenheid van "GitHub user" verandert.

De afgelopen tien jaar was een GitHub-gebruiker een persoon. Die persoon opende een paar PR's per dag, beoordeelde er nog een paar, pushte commits in geconcentreerde uitbarstingen tijdens werkuren en ging naar huis. Hun belastingsprofiel was onrustig, tijdzone-verankerd en uiteindelijk begrensd door het aantal toetsaanslagen dat een mens kan produceren.

De nieuwe GitHub-gebruiker is gedeeltelijk of volledig een agent. Het slaapt niet. Er zijn geen werktijden. Het genereert een PR telkens wanneer CI een zwakke test markeert, een afhankelijkheid verouderd raakt, een documentatieafwijking wordt gedetecteerd of een functievlag moet worden opgeschoond. Het maakt geen kleine commits; het maakt gestructureerde, door tools gegenereerde commits die vaak veel bestanden tegelijk betreffen.

Wanneer u de bursty-bounded menselijke belasting vervangt door een continu-onbegrensde agentload, gebeuren er drie dingen tegelijkertijd met uw infrastructuur:

• Piek-gemiddelde-verhoudingen worden kleiner. GitHub had vroeger nachten en weekenden. Dat doet het niet meer. De grens tussen "piekbelasting" en "achtergrondbelasting" verdwijnt, en je moet ervoor zorgen dat de piek het nieuwe gemiddelde is.
• De gemiddelde objectgrootte neemt toe. Agents produceren grotere verschillen en rijkere PR-beschrijvingen. PR-aanrakende subsystemen - diff-rendering, samenvoegbaarheidscontroles, review-threading - betaal daarvoor met meer CPU, meer geheugen en meer indexwerk.
• Cascade-waarschijnlijkheidspieken. Een schilferige webhook betekende vroeger een enigszins vertraagde melding. Als er agenten in de lus zijn, kan een slechte webhook een vastgelopen automatiseringspijplijn betekenen, wat betekent dat de agent het opnieuw probeert, wat meer API-aanroepen betekent, wat betekent dat het systeem dat al problemen had, zwaarder wordt belast.

Ik heb ze allemaal in mijn eigen werk gevoeld. Afgelopen kwartaal heb ik ruwweg vier Claude Code-agents parallel uitgevoerd op een klantproject: één die tests schreef, één die ze repareerde, één de documentatie bijwerkte, en één PR's beoordeelde. Elke agent voelde zich individueel goedkoop. Samen genereerden ze op een middag meer GitHub API verkeer dan ik in een week handmatig zou hebben gegenereerd. En ik was een ontwikkelaar. Vermenigvuldig dat met de wereldwijde populatie van agentische ontwikkelaars, die van 'early adopters' naar 'mainstream' is gegaan in ongeveer hetzelfde tijdsbestek waarin de belasting van GitHub verdubbelde.

Dit is het echte verhaal van de GitHub-beschikbaarheidscrisis van april 2026, geproduceerd. Niet "GitHub heeft een slechte week gehad." Het is "het belastingmodel waarvoor het platform is ontworpen, is vervangen door een ander belastingmodel, en de architectonische schuld van die mismatch werd publiekelijk opeisbaar."

Als je een scherper beeld wilt krijgen van hoe agentische workflows dit jaar de dominante kracht op ontwikkelplatforms zijn geworden, heb ik de eerdere signalen hiervan besproken in de Anthropic Agent SDK-handleiding en het Claude Code agentic OS-framework – de rode draad van dit alles is dat de tools die we vieren als de productiviteit wint ook stresstests voor de infrastructuur zijn, en GitHub is het eerste grote platform waar de rekening luid genoeg kwam om het nieuws te halen.

Wat dit betekent voor hoe u voortbouwt op GitHub

Laat mij tactisch worden. Als je iets bouwt dat afhankelijk is van GitHub – en als je in 2026 een werkende ontwikkelaar bent, dan ben je dat – zijn er vijf concrete aanpassingen die de moeite waard zijn om in de komende dertig dagen door te voeren.

Scheid eerst "GitHub is actief" van "GitHub UI is actief" in uw monitoring. Het incident van 27 april bewees dat dit verschillende statussen zijn. Als uw tooling wacht tot de GitHub-statuspagina rood wordt voordat deze problemen omzeilt, komt u te laat. Voeg directe API-statustests toe voor de specifieke eindpunten waarvan uw workflow afhankelijk is – gh pr list tegen een bekende repo, een zoekopdracht waarvan u weet dat deze resultaten zou moeten opleveren – en behandel gedeeltelijke degradatie als een actiesignaal, niet alleen als een informatiesignaal.

Ten tweede: vertrouw op de API en CLI, en niet op de web-UI, voor elke workflow die je niet kunt missen. De pull requests bestond op 27 april. De CLI zag ze de hele tijd. Als het incidentplaybook van uw team afhankelijk is van mensen die door de PR-lijstweergaven klikken, wordt uw incidentplaybook verbroken wanneer de zoeklaag kapot gaat. Als het draaiboek door gh en API loopt, gebeurt dit niet.

Ten derde: controleer uw agenten op het gedrag van nieuwe pogingen. Elke agentworkflow die ik ooit heb verzonden, heeft op een gegeven moment een storm van nieuwe pogingen vertoond tijdens een stroomafwaarts incident, waardoor het incident voor iedereen, inclusief zichzelf, verergerde. Exponentiële back-off, jitter en stroomonderbrekers zijn niet optioneel voor elke agent die GitHub raakt. Als uw agent niet over alle drie beschikt, zal de volgende storing moeilijker zijn voor u en voor GitHub.

Ten vierde: behandel weergaven met zoekondersteuning als fundamenteel minder betrouwbaar dan directe zoekopdrachten. Dit is een architectuurles voor de lange termijn, niet een GitHub-specifieke les. Elke keer dat een gebruikersinterface afhankelijk is van een zoekindex, bent u afhankelijk van een systeem waarvan de herbouwtijden in uren worden gemeten. Als uw workflow directe zoekopdrachten kan gebruiken (PR op nummer, commit op SHA, uitgifte op ID), geeft u daar de voorkeur aan. Bewaar door zoekopdrachten ondersteunde zoekopdrachten voor echt verkennende gebruiksscenario's.

** Ten vijfde — en dit is degene die de meeste teams overslaan — voeg een "GitHub sierlijke degradatie"-modus toe aan alles wat je aan het bouwen bent.** Wat doet je tool als GitHub actief is, maar traag? Wanneer het gedeeltelijke resultaten retourneert? Wanneer webhooks vijf minuten worden vertraagd in plaats van vijf seconden? De meeste tools die ik heb gezien zijn 'GitHub werkt' of 'alles explodeert'. Er is een enorme middenweg die het waard is om voor te ontwerpen.

Wat ik fout had, en waar ik nu naar kijk

Ik zal eerlijk zijn over iets waarvan ik dacht dat het hierbij betrokken zou zijn. Toen het incident van 31 maart plaatsvond, las ik het als eenmalig en ging verder. Ik heb het niet aangesloten op de belastingscurve. Ik had niet verwacht dat we binnen vier weken nog twee incidenten zouden zien op verschillende lagen van hetzelfde platform. De corruptie van de merge-wachtrijen van 23 april registreerde nauwelijks voor mij omdat geen van mijn projecten die dag merge-wachtrijen gebruikte. Op 27 april was het patroon onmiskenbaar.

De les die ik hieruit trek is dat infrastructuurincidenten op deze schaal doorgaans niet als één enkele dramatische mislukking ontstaan. Ze komen als een cluster van samenhangende kleinere mislukkingen die elk afzonderlijk verklaarbaar lijken en alleen zinvol zijn als je ze als één verhaal leest. Als je wacht tot die ene grote storing optreedt, mis je de waarschuwingsschoten.

Waar ik de rest van 2026 naar kijk:

• Of de capaciteitsuitbreiding van GitHub de belastingscurve voor blijft. De 30x-doelstelling is gewaagd, maar de curve beweegt ook. Als agentische workflows in de tweede helft van het jaar opnieuw versnellen, beweegt het doel mee. - Of concurrenten nu serieus worden. GitLab, Codeberg, Forgejo en zelf-gehoste Gitea-instances profiteren allemaal van een aanhoudend betrouwbaarheidsgat bij GitHub. Ik verwacht geen massale migratie, maar ik verwacht wel de vraag "is GitHub nog steeds de standaard?" vraag die in meer architectuurbijeenkomsten naar voren zal komen dan zes maanden geleden. - Of agentische workflows zelf beleefder worden. Er is een argument dat de agenten die deze belasting produceren er slimmer mee om kunnen gaan: batching, caching, respect voor back-off, het vermijden van onnodige polling. De eerste golf van agentische tools die zijn geoptimaliseerd voor capaciteiten.

De tweede golf zal moeten optimaliseren om een ​​goede burger te zijn op gedeelde infrastructuur. - Of de monoliet-naar-Go-migratie op tijd wordt verzonden. Dit is het item met de hoogste hefboomwerking op de routekaart van GitHub, en ook het langzaamste. Jaren werk. Als ze het goed uitvoeren, ziet GitHub er bij 30x belasting prima uit. Als ze dat niet doen, voeren we in 2027 hetzelfde gesprek over een ander incident.

Waar ik steeds op terugkom is dat GitHub op deze schaal niet langer alleen maar een product is. Het is infrastructuur. Het is het knelpunt waar een aanzienlijk percentage van de software in de wereld doorheen stroomt op weg van idee naar productie. Wanneer uw chokepoint een slechte maand heeft, rimpelen de gevolgen naar buiten op manieren die moeilijk te meten maar gemakkelijk te voelen zijn.

Veelgestelde vragen

Wat veroorzaakte de GitHub pull-request-bug in april 2026?

De zichtbaarheidsbug van 27 april voor pull-aanvragen werd veroorzaakt doordat het ElasticSearch-cluster, dat door zoekopdrachten ondersteunde weergaven aanstuurt, overbelast raakte, naar verluidt onder botnetgestuurd verkeer. PR's leken te ontbreken in lijstweergaven omdat deze weergaven afhankelijk zijn van zoekindexen, maar de onderliggende gegevens gingen nooit verloren en bleven toegankelijk via de GitHub API en CLI. Voor de architectonische uitsplitsing, zie "Waarom GitHub niet beschikbaar is, is het verkeerde mentale model" hierboven.

Heeft GitHub gegevens verloren tijdens de incidenten van april 2026?

Nee. Bij geen van de incidenten van april 2026 – corruptie van de merge-wachtrij op 23 april, overbelasting van ElasticSearch op 27 april – was er sprake van gegevensverlies. Core Git-bewerkingen, repository's en de API bleven werken. Bij het eerdere incident van 31 maart 2026 was sprake van gegevensverlies met een verminderde beschikbaarheid van ongeveer zes uur.

Wat is het 30x schaalplan van GitHub?

GitHub startte in oktober 2025 met een capaciteitsuitbreiding van 10x en stelde vervolgens de doelstelling bij naar 30x in februari 2026 nadat agent AI workflows de platformbelasting in 6-8 maanden had doen verdubbelen. Het plan omvat het isoleren van kritieke services, het migreren van hot paths van Ruby naar Go, het verplaatsen van webhooks uit MySQL en het voortzetten van de Azure-migratie. Zie "Het 30x-getal dat elke engineer zou moeten laten stoppen" hierboven voor het volledige overzicht.

Welke invloed heeft agent AI workflows op de infrastructuur van GitHub?

Agent-workflows vervangen de onstuimige, in de tijdzone verankerde menselijke belasting door een continue, onbegrensde agentbelasting. Agenten openen PR's, push commits en roepen API's aan zonder slaapcycli, waardoor de piek-tot-gemiddelde verhoudingen worden gecomprimeerd, de gemiddelde objectgrootte wordt vergroot en de cascadewaarschijnlijkheid tijdens incidenten wordt vergroot. De CTO-update van GitHub noemt het versnellen van agentische workflows sinds eind 2025 rechtstreeks als een primaire drijfveer van het herziene schaaldoel.

Moet ik na april 2026 migreren van GitHub?

Voor de meeste teams niet. De kern-Git-laag van GitHub bleef stabiel tijdens de incidenten van april 2026, en geen enkele openbare roadmap van GitLab, Codeberg of Forgejo komt momenteel overeen met het feature-oppervlak van GitHub. De juiste zet is om uw tools te beschermen tegen gedeeltelijke degradatie van GitHub - geef de voorkeur aan API en CLI boven de webinterface voor kritieke workflows, voeg elegante degradatiemodi toe en controleer uw agenten op nieuwe pogingen. Zie "Wat dit betekent voor hoe u voortbouwt op GitHub" hierboven.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io