GitLab voert wijzigingen door in de rate limits op GitLab.com om de groeiende belasting op het platform op te vangen. Vanaf 19 oktober 2026 worden de limieten voor gratis accounts en niet-geauthentiseerde verzoeken aangepast, gevolgd door Premium- en Ultimate-abonnementen in januari 2027.
De belangrijkste punten zijn:
- Abonnementsgebonden limieten: Limieten worden bepaald per gebruiker en top-level groep. Niet-geauthentiseerde aanvragen worden beperkt tot 60 per uur per IP-adres.
- Preview-vensters: Op 7 en 14 oktober vinden er 'brownouts' plaats voor Free- en niet-geauthenticeerd verkeer om gebruikers de kans te geven hun workloads te testen.
- Adviezen voor gebruikers: Om limieten te vermijden, adviseert GitLab het gebruik van authenticatie (tokens), batching, caching en het implementeren van exponential backoff bij HTTP 429-fouten.
- Reikwijdte: De wijzigingen gelden uitsluitend voor GitLab.com. GitLab Self-Managed en Dedicated blijven ongewijzigd. Bovendien blijven UI-browsing, Git push/pull en CI/CD binnen het plan onbeïnvloed.
Rate limits op GitLab.com wijzigen
Vanaf 19 oktober worden de rate limits op GitLab.com afgestemd op je abonnement. Meld je aan om hogere limieten te ontgrendelen. De wijzigingen voor Premium- en Ultimate-abonnementen gaan in januari in.
GitLab.com host miljoenen projecten voor teams van elke omvang die een platform nodig hebben waar ze op kunnen vertrouwen. De vraag stijgt snel en we verwachten dat de belasting van het platform dit jaar met meerdere malen zal toenemen. Voorspelbare limieten zijn essentieel om GitLab.com snel te houden voor iedereen, inclusief de automatisering en agent-workloads die teams op het platform bouwen.
Om dit te waarborgen terwijl we schalen, passen we de werking van de rate limits aan. Vanaf 19 oktober 2026 worden de rate limits op GitLab.com afgestemd op je abonnementstype. De wijzigingen voor gratis accounts en niet-geauthentiseerde verzoeken gaan eerst in op 19 oktober. Premium en Ultimate volgen in januari 2027.
Wat verandert er?
De limieten worden gekoppeld aan je abonnement. De abonnementen Free, Premium en Ultimate krijgen hun eigen limieten, die worden toegepast per gebruiker en per top-level groep.
- Free: gaat in op 19 oktober.
- Premium en Ultimate: gaan in op januari 2027.
Door in te loggen krijg je toegang tot de volledige limiet. Een geauthentiseerde aanvraag wordt beheerst door het onderstaande abonnementsplan. Een aanvraag die binnenkomt zonder inloggegevens (credentials) krijgt een limiet van 60 aanvragen per uur per IP-adres.
De limieten per plan zijn gepubliceerd in de documentatie over rate limits.
Wat gebeurt er op 19 oktober?
Er zullen twee preview-vensters zijn voor Free- en niet-geauthentiseerd verkeer op 7 oktober en 14 oktober, van 15:00 tot 19:00 UTC. Geauthentiseerde Premium- en Ultimate-aanvragen worden hierdoor niet beïnvloed, aangezien die limieten pas in januari wijzigen. Niet-geauthentiseerde aanvragen zijn beperkt, ongeacht waar ze vandaan komen, inclusief automatisering die wordt uitgevoerd tegen een betaald account zonder inloggegevens.
Een preview-venster (door engineers ook wel brownouts genoemd) is een kort, gepland tijdsbestek waarin we de nieuwe limieten inschakelen en daarna weer uitschakelen. Er verandert verder niets aan de service tijdens dit venster. Het doel is om je een realistisch beeld te geven van hoe je eigen workloads zich gedragen onder de nieuwe limieten, weken voordat ze definitief van kracht worden.
Op 19 oktober treden de nieuwe limieten definitief in werking.
We hebben deze limieten vastgesteld door te kijken naar hoe GitLab.com daadwerkelijk wordt gebruikt. Bijna alle gebruikers vallen al binnen de nieuwe limieten en zullen geen verschil merken. We hebben ook gekeken naar wat vergelijkbare platforms toestaan. De limiet voor Free en de anonime toestemming komen overeen met de industrienorm, terwijl Premium en Ultimate royaler zijn; op niveaus die andere platforms reserveren voor hun enterprise-tiers of helemaal niet publiceren.
Als je dicht bij een limiet komt
Als je merkt dat je een limiet nadert, is het raadzaam om je aanvragen te authentificeren. Dit is meestal een kleine aanpassing: het gebruik van een personal access token, een OAuth token of het CI/CD job token verplaatst een aanvraag van de anonieme limiet van 60 aanvragen per uur naar de limieten van je plan, die veel hoger liggen.
Kijk daarnaast naar de manier waarop je de API aanroept:
- Batching, caching en paginering helpen aanzienlijk.
- Polling in een strakke loop verbruikt je budget zeer snel.
Wanneer je een limiet overschrijdt, ontvang je een HTTP 429 response met een Retry-After header die aangeeft hoe lang je moet wachten. Een client die zijn eigen response-headers leest, lost dit grotendeels automatisch op. Exponential backoff (exponentieel wachten) herstelt sneller dan onmiddellijk opnieuw proberen.
Een upgrade naar Premium of Ultimate verhoogt de limieten per gebruiker en per top-level groep.
Als je structureel een hogere limiet nodig hebt, werken we aan een mogelijkheid om extra capaciteit boven de standaard planlimieten aan te schaffen; details hierover volgen later dit jaar. Indien dit op jou van toepassing is, kun je contact opnemen met je accountteam of mailen naar limits@gitlab.com.
Wat verandert er wel en wat niet?
Deze limieten zijn zo ingesteld dat geen enkele individuele workload het platform voor anderen kan vertragen. Normaal gebruik door ingelogde gebruikers is niet het doelwit; voor bijna alle gebruikers ziet een normale werkdag er identiek uit.
Het volgende blijft ongewijzigd:
- Het browsen via de UI.
- Werken in je editor.
- Het pushen en pullen met Git.
- Het uitvoeren van CI/CD binnen je plan.
Sommige zware automatisering en een klein aantal workloads in de Free-tier zullen de nieuwe plafonds wel bereiken.
Wat er absoluut niet verandert:
- Je kunt altijd je eigen data en repositories bereiken en exporteren.
- Limieten voor GitLab Self-Managed en GitLab Dedicated blijven in beheer van de operator. Dit is uitsluitend een wijziging voor GitLab.com.
- We zullen je informeren voordat we verdere wijzigingen doorvoeren.
Herinnering: Zorg ervoor dat je je aanvragen naar GitLab.com authentificeert, zodat je hogere limieten hebt.
FAQ
Hoe weet ik of dit mij beïnvloedt? Vergelijk je drukste minuut met de gepubliceerde limieten voor jouw plan. De meeste klanten zitten hier niet dichtbij. Het snelste signaal is momenteel de RateLimit-Remaining header in je API-responses, die aangeeft hoeveel van je huidige venster nog over is. We bouwen momenteel een weergave in het product (release later dit jaar) die je verbruik ten opzichte van je planlimieten toont.
Mijn project is openbaar en druk. Wat zijn mijn opties? Drie zaken kunnen helpen:
- Vraag de automatisering die je project aanroept om in te loggen; dit verplaatst de aanvragen naar eigen limieten in plaats van de anonieme toestemming.
- Maak het project privé als het verkeer niet afkomstig is van het publiek waarvoor je het gebouwd hebt; dit stopt anonieme callers volledig.
- Upgrade naar Premium of Ultimate voor aanzienlijk hogere limieten.
Wat als ik lid ben van meerdere top-level groepen? Je gebruikerslimiet wordt bepaald door het hoogste abonnementstype dat voor jou beschikbaar is. Als je lid bent van een Ultimate-groep, heb je toegang tot de Ultimate-limiet.
Wat gebeurt er als ik een limiet bereik? Je ontvangt een 429 Too Many Requests met RateLimit-* headers en een Retry-After. Wacht het aangegeven interval en probeer het dan opnieuw.
Mijn integratie kan echt niet authentificeren. Wat nu? Neem contact met ons op via limits@gitlab.com. Er zijn legitieme anonieme patronen, zoals een publieke status-badge. Als je bezorgd bent dat een integratie die jij beheert beïnvloed wordt, neem dan contact op.
Is dit van toepassing op GitLab Self-Managed of GitLab Dedicated? Nee. Dit is een wijziging die alleen geldt voor GitLab.com.
Aanvullende bronnen
- Rate limits per plan
- Het authentificeren van je API-aanvragen
Heb je vragen of ben je een scenario tegengekomen waar we niet aan hebben gedacht? Neem contact op met je accountteam of mail naar limits@gitlab.com.
Rate limits op GitLab.com wijzigen
Vanaf 19 oktober worden de rate limits op GitLab.com afgestemd op je abonnement. Meld je aan om hogere limieten te ontgrendelen. De wijzigingen voor Premium- en Ultimate-abonnementen gaan in januari in.
GitLab.com host miljoenen projecten voor teams van elke omvang die een platform nodig hebben waar ze op kunnen vertrouwen. De vraag stijgt snel en we verwachten dat de belasting van het platform dit jaar met meerdere malen zal toenemen. Voorspelbare limieten zijn essentieel om GitLab.com snel te houden voor iedereen, inclusief de automatisering en agent-workloads die teams op het platform bouwen.
Om dit te waarborgen terwijl we schalen, passen we de werking van de rate limits aan. Vanaf 19 oktober 2026 worden de rate limits op GitLab.com afgestemd op je abonnementstype. De wijzigingen voor gratis accounts en niet-geauthentiseerde verzoeken gaan eerst in op 19 oktober. Premium en Ultimate volgen in januari 2027.
Wat verandert er?
De limieten worden gekoppeld aan je abonnement. De abonnementen Free, Premium en Ultimate krijgen hun eigen limieten, die worden toegepast per gebruiker en per top-level groep.
- Free: gaat in op 19 oktober.
- Premium en Ultimate: gaan in op januari 2027.
Door in te loggen krijg je toegang tot de volledige limiet. Een geauthentiseerde aanvraag wordt beheerst door het onderstaande abonnementsplan. Een aanvraag die binnenkomt zonder inloggegevens (credentials) krijgt een limiet van 60 aanvragen per uur per IP-adres.
De limieten per plan zijn gepubliceerd in de documentatie over rate limits.
Wat gebeurt er op 19 oktober?
Er zullen twee preview-vensters zijn voor Free- en niet-geauthentiseerd verkeer op 7 oktober en 14 oktober, van 15:00 tot 19:00 UTC. Geauthentiseerde Premium- en Ultimate-aanvragen worden hierdoor niet beïnvloed, aangezien die limieten pas in januari wijzigen. Niet-geauthentiseerde aanvragen zijn beperkt, ongeacht waar ze vandaan komen, inclusief automatisering die wordt uitgevoerd tegen een betaald account zonder inloggegevens.
Een preview-venster (door engineers ook wel brownouts genoemd) is een kort, gepland tijdsbestek waarin we de nieuwe limieten inschakelen en daarna weer uitschakelen. Er verandert verder niets aan de service tijdens dit venster. Het doel is om je een realistisch beeld te geven van hoe je eigen workloads zich gedragen onder de nieuwe limieten, weken voordat ze definitief van kracht worden.
Op 19 oktober treden de nieuwe limieten definitief in werking.
We hebben deze limieten vastgesteld door te kijken naar hoe GitLab.com daadwerkelijk wordt gebruikt. Bijna alle gebruikers vallen al binnen de nieuwe limieten en zullen geen verschil merken. We hebben ook gekeken naar wat vergelijkbare platforms toestaan. De limiet voor Free en de anonime toestemming komen overeen met de industrienorm, terwijl Premium en Ultimate royaler zijn; op niveaus die andere platforms reserveren voor hun enterprise-tiers of helemaal niet publiceren.
Als je dicht bij een limiet komt
Als je merkt dat je een limiet nadert, is het raadzaam om je aanvragen te authentificeren. Dit is meestal een kleine aanpassing: het gebruik van een personal access token, een OAuth token of het CI/CD job token verplaatst een aanvraag van de anonieme limiet van 60 aanvragen per uur naar de limieten van je plan, die veel hoger liggen.
Kijk daarnaast naar de manier waarop je de API aanroept:
- Batching, caching en paginering helpen aanzienlijk.
- Polling in een strakke loop verbruikt je budget zeer snel.
Wanneer je een limiet overschrijdt, ontvang je een HTTP 429 response met een Retry-After header die aangeeft hoe lang je moet wachten. Een client die zijn eigen response-headers leest, lost dit grotendeels automatisch op. Exponential backoff (exponentieel wachten) herstelt sneller dan onmiddellijk opnieuw proberen.
Een upgrade naar Premium of Ultimate verhoogt de limieten per gebruiker en per top-level groep.
Als je structureel een hogere limiet nodig hebt, werken we aan een mogelijkheid om extra capaciteit boven de standaard planlimieten aan te schaffen; details hierover volgen later dit jaar. Indien dit op jou van toepassing is, kun je contact opnemen met je accountteam of mailen naar limits@gitlab.com.
Wat verandert er wel en wat niet?
Deze limieten zijn zo ingesteld dat geen enkele individuele workload het platform voor anderen kan vertragen. Normaal gebruik door ingelogde gebruikers is niet het doelwit; voor bijna alle gebruikers ziet een normale werkdag er identiek uit.
Het volgende blijft ongewijzigd:
- Het browsen via de UI.
- Werken in je editor.
- Het pushen en pullen met Git.
- Het uitvoeren van CI/CD binnen je plan.
Sommige zware automatisering en een klein aantal workloads in de Free-tier zullen de nieuwe plafonds wel bereiken.
Wat er absoluut niet verandert:
- Je kunt altijd je eigen data en repositories bereiken en exporteren.
- Limieten voor GitLab Self-Managed en GitLab Dedicated blijven in beheer van de operator. Dit is uitsluitend een wijziging voor GitLab.com.
- We zullen je informeren voordat we verdere wijzigingen doorvoeren.
Herinnering: Zorg ervoor dat je je aanvragen naar GitLab.com authentificeert, zodat je hogere limieten hebt.
FAQ
Hoe weet ik of dit mij beïnvloedt? Vergelijk je drukste minuut met de gepubliceerde limieten voor jouw plan. De meeste klanten zitten hier niet dichtbij. Het snelste signaal is momenteel de RateLimit-Remaining header in je API-responses, die aangeeft hoeveel van je huidige venster nog over is. We bouwen momenteel een weergave in het product (release later dit jaar) die je verbruik ten opzichte van je planlimieten toont.
Mijn project is openbaar en druk. Wat zijn mijn opties? Drie zaken kunnen helpen:
- Vraag de automatisering die je project aanroept om in te loggen; dit verplaatst de aanvragen naar eigen limieten in plaats van de anonieme toestemming.
- Maak het project privé als het verkeer niet afkomstig is van het publiek waarvoor je het gebouwd hebt; dit stopt anonieme callers volledig.
- Upgrade naar Premium of Ultimate voor aanzienlijk hogere limieten.
Wat als ik lid ben van meerdere top-level groepen? Je gebruikerslimiet wordt bepaald door het hoogste abonnementstype dat voor jou beschikbaar is. Als je lid bent van een Ultimate-groep, heb je toegang tot de Ultimate-limiet.
Wat gebeurt er als ik een limiet bereik? Je ontvangt een 429 Too Many Requests met RateLimit-* headers en een Retry-After. Wacht het aangegeven interval en probeer het dan opnieuw.
Mijn integratie kan echt niet authentificeren. Wat nu? Neem contact met ons op via limits@gitlab.com. Er zijn legitieme anonieme patronen, zoals een publieke status-badge. Als je bezorgd bent dat een integratie die jij beheert beïnvloed wordt, neem dan contact op.
Is dit van toepassing op GitLab Self-Managed of GitLab Dedicated? Nee. Dit is een wijziging die alleen geldt voor GitLab.com.
Aanvullende bronnen
- Rate limits per plan
- Het authentificeren van je API-aanvragen
Heb je vragen of ben je een scenario tegengekomen waar we niet aan hebben gedacht? Neem contact op met je accountteam of mail naar limits@gitlab.com.
Groetjes,