GitHub Actions Cache krijgt limiet van 200 uploads per minuut

Rongchai Wang
17 jan 2026 09:16

GitHub introduceert snelheidsbeperking voor Actions-cache-items op 200 uploads per minuut per repository, om problemen met systeemstabiliteit door grote volumes uploads aan te pakken.

GitHub heeft een nieuwe snelheidsbeperking geïmplementeerd op zijn Actions-cachesysteem, waarbij uploads worden beperkt tot 200 nieuwe cache-items per minuut voor elke repository. De wijziging, aangekondigd op 16 januari 2026, richt zich op repositories die het cachesysteem overbelasten met snelle uploads en stabiliteitsproblemen veroorzaken op het hele platform.

Downloads blijven onaangetast. Als uw workflows bestaande cache-items ophalen, verandert er niets. De limiet richt zich specifiek op het aanmaken van nieuwe items—een onderscheid dat belangrijk is voor teams die parallelle builds uitvoeren die nieuwe cachegegevens genereren.

Waarom nu? GitHub noemde "cache thrash" als de boosdoener. Repositories die enorme volumes cache-items in korte bursts uploaden, verslechterden de prestaties voor alle anderen op de gedeelde infrastructuur. De limiet van 200 per minuut geeft intensieve gebruikers voldoende ruimte voor legitieme gebruikssituaties, terwijl het soort misbruik wordt voorkomen dat het systeem destabiliseerde.

Onderdeel van een Bredere Actions-Herziening

Deze snelheidsbeperking komt te midden van verschillende significante wijzigingen in de economie van GitHub Actions. Eerder deze maand verlaagde GitHub de prijzen voor gehoste runners met 15% tot 39%, afhankelijk van de grootte. Maar het grotere nieuws komt op 1 maart 2026, wanneer het gebruik van zelf-gehoste runners in privé-repo's $0,002 per minuut gaat kosten—een nieuwe kostenpost die sommige teams doet heroverwegen hun CI/CD-architectuur volledig te herzien.

Het cachesysteem zelf kreeg eind 2025 een upgrade, waarbij repositories nu de eerdere limiet van 10 GB kunnen overschrijden via pay-as-you-go-prijzen. Elke repo krijgt nog steeds 10 GB gratis, maar intensieve gebruikers kunnen nu meer kopen in plaats van voortdurend te strijden tegen verwijderingsbeleid.

Wat Teams Moeten Controleren

De meeste workflows zullen deze limiet niet merken. Maar als u matrix-builds uitvoert die unieke cachesleutels genereren over tientallen parallelle taken, doe dan de berekening. Een matrix van 50 taken die gelijktijdig worden voltooid, kan theoretisch 200 cache-uploads bereiken in minder dan een minuut als elke taak meerdere items aanmaakt.

De oplossing is eenvoudig: consolideer waar mogelijk cachesleutels, of spreid de voltooiing van taken als u echt tegen het plafond aanloopt. GitHub heeft geen monitoringdashboard voor cache-uploadsnelheden aangekondigd, dus teams die zich zorgen maken over het bereiken van limieten, zullen hun workflow-logboeken handmatig moeten controleren.

Afbeeldingsbron: Shutterstock