429 Too Many Requests bedeutet, dass der Server Sie per Rate Limit bremst: Der Client hat in einem Zeitraum mehr Anfragen gesendet, als der Server zulässt, und sollte warten, bevor er es erneut versucht. Nichts ist kaputt, und die Anfrage sofort zu wiederholen macht es schlimmer. Ein gut konfigurierter Server sagt in einem Retry-After-Header, wie lange gewartet werden soll; ein gut programmierter Client wartet mindestens so lange und verlängert ohne diesen Header die Pausen schrittweise. Läuft ein Monitor in einen 429, ist die übliche Lösung, den Monitor vom Limit auszunehmen oder einen Endpunkt ohne Limit zu prüfen.
So funktioniert Rate Limiting
RFC 6585 definiert 429, überlässt die Regeln aber jedem Server selbst. Ein Limit besteht aus drei Teilen:
Wer gezählt wird: eine IP-Adresse, ein API-Schlüssel, ein Benutzerkonto oder eine Kombination. Limits pro IP zählen alle hinter derselben Adresse zusammen.
Was gezählt wird: alle Anfragen oder nur bestimmte, etwa Logins, Suchen oder ein aufwendiger API-Endpunkt, oft mit einem strengeren Limit.
Wie die Zeit gezählt wird: Ein festes Fenster wird zur vollen Minute zurückgesetzt; ein gleitendes Fenster betrachtet die letzten 60 Sekunden; ein Token Bucket füllt sich mit gleichmäßiger Rate auf und erlaubt kurze Bursts bis zu seiner Größe.
Die Antwort verrät oft, wo Sie stehen:
HTTP/2 429
retry-after: 30
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1793091600
Retry-After ist standardisiert und enthält entweder eine Anzahl Sekunden oder ein HTTP-Datum. Die X-RateLimit-*-Header sind eine verbreitete Konvention statt eines Standards, und ihre Bedeutung variiert: reset kann ein Unix-Zeitstempel oder eine Anzahl Sekunden sein, lesen Sie also die Dokumentation der API. Ein IETF-Entwurf definiert die Standardfelder RateLimit und RateLimit-Policy, die einige APIs bereits senden.
Woher 429-Fehler kommen
Drittanbieter-APIs, die Sie aufrufen, etwa Zahlungs-, E-Mail-, Karten- oder Chatdienste, die jeden Schlüssel oder jedes Konto begrenzen.
Ihr eigenes API-Gateway oder Framework, über Rate-Limiting-Middleware.
Ihr Webserver. nginx’ limit_req antwortet standardmäßig mit 503; setzen Sie limit_req_status 429, damit Clients wissen, dass sie langsamer werden sollen, statt einen Ausfall anzunehmen.
CDNs und WAFs, über Rate-Limiting-Regeln. Je nach Regel lautet die Antwort 429, 403 oder eine Challenge-Seite.
Login- und Formularschutz in einem CMS oder Sicherheits-Plugin, der die Versuche pro Adresse begrenzt.
Einen 429 als Client behandeln
Retry-After beachten. Warten Sie mindestens so lange wie angegeben. Wer früher erneut versucht, bekommt meist den nächsten 429 und kann eine Sperre verlängern.
Exponentielles Backoff mit Jitter. Ohne Retry-After warten Sie nach jedem Fehlschlag länger, zum Beispiel 1, 2, 4 und 8 Sekunden, plus einen Zufallsanteil, damit nicht viele Clients im selben Moment erneut anfragen.
Wiederholungen begrenzen. Geben Sie nach einigen Versuchen auf und melden Sie den Fehler, oder stellen Sie die Arbeit für später in eine Warteschlange.
Weniger Anfragen senden. Cachen Sie Antworten, nutzen Sie Batch-Endpunkte, fragen Sie größere Seiten ab, und setzen Sie Webhooks statt Polling ein, wo die API sie anbietet.
Geplante Aufgaben verteilen. Cron-Jobs, die alle zur vollen Stunde starten, laufen gemeinsam ins Limit; versetzen Sie sie um ein paar Minuten. Wie das geht, zeigt der Leitfaden zu Cron-Ausdrücken.
async function fetchWithBackoff(url, options = {}, attempts = 5) {
for (let attempt = 0; attempt < attempts; attempt++) {
const response = await fetch(url, options);
if (response.status !== 429) return response;
const retryAfter = Number(response.headers.get(‚retry-after‘));
const wait = retryAfter > 0 ? retryAfter * 1000 : 2 ** attempt * 1000 + Math.random() * 1000;
await new Promise((resolve) => setTimeout(resolve, wait));
}
throw new Error(‚Still rate limited after ‚ + attempts + ‚ attempts‘);
}
Diese Skizze liest Retry-After nur als Sekunden; Produktionscode sollte auch die Datumsform akzeptieren.
Rate Limits auf der eigenen Website setzen
Mit 429 antworten, nicht mit 503 oder 403. Ein 503 sieht aus wie ein Ausfall und ein 403 wie eine dauerhafte Ablehnung; ein 429 sagt Clients und Monitoring-Tools genau, was passiert ist.
Retry-After senden, damit Clients nicht raten müssen.
Wo möglich pro Schlüssel oder Konto begrenzen. Limits pro IP bestrafen Büros, Schulen und Mobilfunknetze, in denen sich viele Menschen eine Adresse teilen.
Bursts zulassen. Ein Seitenaufruf kann Dutzende Anfragen auf einmal auslösen; ein Token Bucket mit Platz für einen Burst verhindert, dass normale Besucher blockiert werden.
Das eigene Monitoring ausnehmen, oder ihm einen eigenen Health-Check-Endpunkt ohne Limit geben.
# nginx: 10 requests a second per address, bursts of 20, answered with 429
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}
Warum ein Uptime-Monitor in einen 429 laufen kann
Ein Check pro Minute klingt harmlos, summiert sich aber auf leicht übersehene Weise:
Mehrere Monitore auf einem Host. Zehn Monitore auf derselben API, die jede Minute prüfen, sind zehn Anfragen pro Minute vom selben Client, plus die bestätigenden Wiederholungs-Checks, wenn etwas fehlschlägt.
Strenge Limits auf dem geprüften Pfad. Login-Seiten, Suche und Formular-Endpunkte erlauben oft nur wenige Anfragen pro Minute und Adresse.
Geteilte Adressen. Die Checks eines Monitoring-Dienstes kommen von wenigen bekannten Adressen. Ein Limit pro IP zählt jeden Check von dieser Adresse zusammen, auch die Checks anderer Nutzer auf dieselbe öffentliche Website oder API.
Eine Bot-Regel mit Rate Limit. Manche Firewalls zählen automatisierte Clients separat und begrenzen sie stärker als Browser.
Was zu tun ist, in dieser Reihenfolge: Nehmen Sie den Monitor über seine IP-Adressen vom Limit aus, überwachen Sie einen Health-Endpunkt ohne Limit, prüfen Sie seltener, oder fassen Sie Monitore zusammen, die dieselbe API abfragen. Werten Sie 429 nicht pauschal als erreichbar, denn ein Limit, das plötzlich Ihre echten Nutzer blockiert, sollten Sie kennen. HTTP-Statuscodes im Monitoring zeigt, welche Codes Sie als Fehler werten sollten, und die Checkliste für API-Monitoring, worauf Sie bei einer API sonst noch achten sollten.
429-Fehler und Uptimecheck
Im Uptime-Monitoring und API-Monitoring von Uptimecheck liegt ein 429 außerhalb der standardmäßig erwarteten Status (200 bis 399) und gilt daher als Ausfall, sobald ein zweiter Check ihn bestätigt. Antwortet der Server mit einem einfachen 429, sagt der Vorfall, dass unsere Checks per Rate Limit gebremst werden, nennt den Retry-After-Wert, sofern der Server einen gesendet hat, und schlägt vor, Anfragen mit „Uptimecheck“ im User-Agent auszunehmen, seltener zu prüfen oder einen Endpunkt ohne das Limit zu nutzen. Checks laufen aus Stockholm, Schweden; So lassen Sie Uptimecheck durch eine Firewall listet die auszunehmenden Adressen auf, mit Regeln für Cloudflare, einschließlich seiner Rate-Limiting-Regeln, und für nginx. Sie legen das Intervall jedes Monitors selbst fest, von jeder Minute bis zu jeder Stunde.
Uptimecheck hält sich beim Versand Ihrer Alarme an dieselben Regeln. Antwortet Slack, Microsoft Teams, Discord oder PagerDuty mit 429, wird der Alarm nach 30 Sekunden, 2 Minuten, 10 Minuten und 30 Minuten erneut gesendet, und nie früher, als der Retry-After des Dienstes verlangt, bis zu einer Stunde. Unter Warum Alarme womöglich nicht ankommen lesen Sie, was passiert, wenn ein Kanal dauerhaft fehlschlägt.
Unterscheiden Sie ein Rate Limit von einem Ausfall. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.