429 Too Many Requests: rate limits, Retry-After en valse alarmen

Wat een 429 betekent en wat erbij komt

429 is gedefinieerd in RFC 6585 als de status voor rate limiting: de client heeft te veel verzoeken verstuurd in een bepaalde tijdspanne. De specificatie laat met opzet twee dingen open: hoe de server de client identificeert, en hoe verzoeken worden geteld. Daarom verschillen rate limits zo sterk tussen diensten.

In de praktijk tellen servers per IP-adres, per API-sleutel, per sessie, per account, of per combinatie daarvan, en gebruiken ze vaste vensters, glijdende vensters of token buckets. Twee identieke verzoeksnelheden kunnen daardoor prima zijn op het ene endpoint en geblokkeerd worden op een ander op dezelfde site.

Het antwoord draagt de signalen die u nodig heeft:

• Retry-After is de standaard. RFC 9110 staat zowel een aantal seconden als een HTTP-datum toe, en een nette client wacht die tijd uit voordat hij het opnieuw probeert.
• Rate-limit-headers zoals RateLimit-Limit, RateLimit-Remaining en RateLimit-Reset, of de oudere X-RateLimit--varianten, tonen het budget en wanneer het reset. Dit zijn conventies, geen onderdeel van RFC 9110, dus controleer de API-documentatie voor de exacte namen.
• De body zou de limiet in mensentaal moeten uitleggen. Veel API's noemen welk quotum werd overschreden, wat een hoop giswerk scheelt.

Een 429 is standaard niet cachebaar, dus tussenliggende partijen zouden hem niet moeten blijven serveren nadat het venster reset.

Rate limit of echte storing?

Deze worden voortdurend door elkaar gehaald, want beide verschijnen als mislukkende verzoeken. De onderscheidende tests gaan snel:

• De code zelf. Een rate limit antwoordt met 429. Een overbelaste of onderhoudsserver antwoordt met 503. Beide kunnen Retry-After dragen, wat precies is waarom mensen ze door elkaar halen, maar ze betekenen iets anders: 429 zegt "u specifiek stuurt te veel", 503 zegt "de dienst als geheel kan nu geen werk aan". Zie de 503-handleiding voor die kant.
• Responstijd. Rate limits weigeren snel, meestal in milliseconden, omdat de beslissing valt voordat er echt werk gebeurt. Overbelasting reageert traag of loopt vast op een time-out.
• Wie er wordt getroffen. Een rate limit raakt één client-identiteit. Test vanaf een ander IP-adres of met een andere API-sleutel: slaagt dat wel terwijl de afgeknepen client nog steeds faalt, dan is het een limiet, geen storing.
• Het patroon door de tijd heen. Rate limiting is periodiek en herstelt vanzelf. Mislukkingen klonteren samen, stoppen dan precies wanneer het venster reset, en keren dan terug. Een storing hervat niet netjes volgens een schema.
• Correlatie met uw eigen volume. Begonnen de mislukkingen toen u een controle-interval verhoogde, parallelle workers toevoegde of een batchtaak startte, dan ligt de oorzaak aan uw kant van de verbinding.

Waarom monitoring zichzelf een 429 kan bezorgen

Monitoring is een herhalend verzoek vanaf een kleine set adressen naar dezelfde URL, wat dicht in de buurt komt van precies de vorm die rate limiters zijn gebouwd om te vangen. Een zeer kort controle-interval maakt dat erger, want elke-minuut-checks vermenigvuldigd met veel bewaakte URL's lopen snel op tegen een budget per IP. Hetzelfde geldt voor een check vanaf veel locaties tegelijk uitvoeren: de oorsprong ziet een uitbarsting in plaats van een gestaag druppeltje, en burstlimieten gaan als eerste af.

De keuze van URL doet er ook toe. Zoekpagina's, API-endpoints en alles wat schrijft, worden meestal harder gelimiteerd dan een statische homepage. En delen monitoring en de applicatie één API-sleutel, dan concurreren de twee om één quotum. Het resultaat is een monitor die de site als falend meldt terwijl de site volkomen gezond is, en een rate limiter die zijn werk correct doet.

Hoe u een 429 oplost

1. Lees de responseheaders voordat u iets verandert:

   curl -sS -o /dev/null -D - https://example.com/api/items

   Retry-After en eventuele rate-limit-headers vertellen u het echte budget, wat beter is dan gokken naar intervallen.
2. Respecteer Retry-After. Meteen opnieuw proberen verlengt bij veel implementaties de blokkade. Wacht de vermelde tijd uit.
3. Bouw exponentieel af met jitter in clientcode, zodat gelijktijdige clients niet synchroon opnieuw proberen in een kuddegedrag.
4. Verlaag het verzoektempo. Zet voor monitoring een gecontroleerd endpoint op een langer interval, of spreid checks zodat niet veel locaties tegelijk in dezelfde seconde afgaan.
5. Monitor een goedkope, representatieve URL. Een lichtgewicht health-endpoint of de homepage vertelt u dat de site up is zonder het quotum te besteden dat u voor echt verkeer nodig heeft.
6. Zonder de monitoringclient uit bij de limiter. Zet de adressen van de controlepunten op een toelatingslijst, of geef monitoring zijn eigen API-sleutel met een eigen budget, zodat het nooit concurreert met productieverkeer.
7. Beheert u de limiter zelf, controleer dan of de limiet klopt. Vraag u af of het budget overeenkomt met echt gebruik, of het per IP is terwijl het per account zou moeten zijn, en of gedeelde proxy's of bedrijfs-NAT veel gebruikers achter één adres zetten.

429's in de gaten houden zonder ze te veroorzaken

Rate limits verschijnen meestal eerst bij de drukste clients, wat betekent dat betalende klanten en integraties ze raken voordat iemand van uw team dat doet. Een geplande HTTP-controle die de verwachte statuscode toetst, toont een 429 als een apart, tijdgestempeld voorval in plaats van als verspreide meldingen dat "de API wispelturig is", en de timing vertelt u of de limiet periodiek of blijvend is. Stel het interval bewust in: vaak genoeg om problemen snel op te merken, mild genoeg dat de controle nooit zelf de limiet laat afgaan. De bredere familie van weigeringen, waaronder 401 en 403, staat in het 4xx-overzicht.