Hvad betyder HTTP-status 429?

HTTP-statuskoden 429 står for “Too Many Requests”. Den bruges, når en server modtager flere anmodninger, end den midlertidigt vil håndtere fra en given klient eller inden for en bestemt periode.

Den centrale pointe er, at 429 ikke nødvendigvis fortæller, at noget er “forkert” i din forespørgsel i almindelig forstand. Ofte handler det om tempo og volumen: hvor hurtigt og hvor ofte der sendes requests.

Hvorfor får man 429?

De mest almindelige årsager kan grupperes som følger:

  1. Rate limiting Serveren beskytter sig mod overbelastning eller misbrug ved at begrænse antallet af anmodninger. Hvis din klient rammer den grænse, udsteder serveren 429.

  2. Retry-mønstre der forstærker problemet Hvis en klient automatisk prøver igen hurtigt efter en fejl, kan retries gøre det værre. Resultatet kan være en “feedback-loop”, hvor flere forsøg i samme tidsrum øger sandsynligheden for endnu flere 429-svar.

  3. Flere samtidige forespørgsler Selv om hvert enkelt request ikke er problematisk, kan et højt antal samtidige kald (parallelisme) føre til overskridelse af serverens grænse.

  4. Dynamiske grænser og kontekst Nogle systemer håndhæver begrænsninger afhængigt af fx rute, type operation, geografi eller tidligere adfærd. Dermed kan det virke som om “det samme” virker en gang, men fejler næste gang.

Hvad er den vigtigste begrænsning eller undtagelse?

En vigtig begrænsning er, at varigheden af 429 kan være kortvarig eller langvarig afhængigt af serverens politik. Uden adgang til serverens interne regler (eller de eventuelle hints, den sender) kan man ikke med sikkerhed forudsige præcist, hvor længe man skal vente.

Derfor bør du behandle 429 som et signal om midlertidig begrænsning, hvor målet er at ændre tempoet på dine requests. Når begrænsningen udløber, bør adfærden ændre sig, men det kræver stadig praktisk test.

Sådan adskiller 429 sig fra andre statuskoder

429 forveksles ofte med andre “fejl”-koder. Her er de nyttige skel:

  • 403 Forbidden: typisk adgang nægtet pga. autorisation/permissions eller politik. 429 handler oftere om tempo.
  • 401 Unauthorized: manglende/ugyldige legitimationsoplysninger.
  • 503 Service Unavailable: ofte generel overbelastning/vedligehold. 429 kan også være relateret til beskyttelse, men er mere specifikt knyttet til anmodningsmængde.
  • 504 Gateway Timeout: timeout i mellemled, ikke nødvendigvis relateret til rate.

Kontrolpunkt: Hvis du ser 429, så fokuser først på anmodningsfrekvens og retry-logik fremfor at antage et login- eller tilladelsesproblem.

Praktiske kontrolpunkter du selv kan teste

Brug følgende punkter til at få 429 under kontrol, uden at gætte:

  1. Mål hvor mange requests du sender pr. tidsenhed Se i dine logs (klient- eller applikationslog) eller i dit overvågningsværktøj: hvor mange kald sker der samlet, og hvor tæt i tid?

  2. Undersøg dit retry-mønster Hvis du automatiserer genforsøg, så tjek om du retry’er med for kort ventetid eller uden “backoff”. Selv en lille justering kan reducere antallet af 429 betydeligt.

  3. Reducer parallelisme midlertidigt Hvis du sender mange samtidige kald, så prøv at begrænse antal samtidige requests og gentag testen. Hvis 429 falder, har du sandsynligvis ramt en rate-grænse.

  4. Sammenlign success/failure mønstre Undersøg om 429 opstår under bestemte handlinger (fx specifikke endpointtyper) eller bestemte tidspunkter. Det hjælper med at skelne mellem “global rate limit” og “operation-specifik” begrænsning.

  5. Observer ændringer efter justering Hvis du ændrer tempo, burde du se færre 429-svar i samme vindue. Hvis 429 fortsætter uændret, er det et tegn på, at problemet kan ligge andre steder (fx uventet loop i klientsiden, caching der ikke virker som forventet, eller at grænsen gælder på en anden nøgle end du tror).

  6. Hvis det ikke bedrer sig: gå i dybden Gentag ikke i det uendelige. Vedvarende 429 efter relevante ændringer bør føre til mere systematisk fejlsøgning: identifikation af hvilke komponenter der genererer traffic, korrelation mod server-side logik (hvis tilgængelig), og kontrol af om der er uforudsete processer (fx opgaver der kører oftere end forventet).

Realistiske scenarier og typiske konsekvenser

  • Scenario: Batchjob med mange rekvisitioner Hvis et job udsender tusindvis af requests hurtigt efter hinanden, kan konsekvensen være 429-bølger. Limitering af tempo eller planlægning af batchen kan give stabil drift.

  • Scenario: Applikation med hurtige genforsøg ved fejl Hvis klienten “misligholder” 429 ved at retry’e aggressivt, kan konsekvensen være længerevarende begrænsning og øget trafik uden fremgang.

  • Scenario: Flere instanser i samme miljø Hvis flere instanser koordinerer en opgave, kan samlet rate overstige grænsen. Konsekvensen er at en del af instanserne typisk oplever 429.

Usikkerhed du skal være opmærksom på

Da 429 kan være knyttet til serverens specifikke rate-limit-politik, kan detaljer som nøjagtig ventetid eller hvilke felter der indgår i begrænsningen variere. Derfor er det bedst at betragte 429 som en anmodningsmængde-problemindikator, og validere effekten af dine ændringer gennem målbare forsøg.

Hvis du vil have mere præcision, afhænger det af de oplysninger, du kan se i dine egne logfiler (og eventuelle standardiserede hints, som serveren måtte levere).