Retry-After wird als Sekunden oder HTTP-Datum geparst. Exponentielle Verzögerung wird begrenzt, deterministischer Jitter ergänzt und kein Versuch vor dem Serverzeitpunkt geplant.
332
Daten & Entwicklung
Retry-After- und Backoff-Planer
Interpretiert Retry-After als Sekunden oder HTTP-Datum und berechnet aus Methodensicherheit, Versuchen, Basis, Obergrenze und deterministischem Jitter den frühesten Zeitplan. Es sendet keine Anfrage.
✓ Kostenlos✓ Kein Konto✓ Im Browser
KURZANTWORT
Was macht dieses Werkzeug?
Retry-Regeln für 429/503, exponentielles Backoff, Jitter und Obergrenzen als Zeitplan darstellen.
ANWENDUNGS- UND ENTSCHEIDUNGSHILFE
Retry-After- und Backoff-Planer: Methode und Anwendung
Interpretiert Retry-After als Sekunden oder HTTP-Datum und berechnet aus Methodensicherheit, Versuchen, Basis, Obergrenze und deterministischem Jitter den frühesten Zeitplan. Es sendet keine Anfrage.
HTTP-Methode, 429- oder 503-Antwort, Retry-After-Wert, Versuchszahl, Basisverzögerung, Obergrenze und Jitter-Prozent Das Format zuerst mit einem kleinen Beispiel ohne Personendaten prüfen.
einen Zeitplan mit Versuchsnummer, Wartezeit, frühestem Retry-Zeitpunkt und Warnung bei unsicherer Methode
Praktische Schritte
- Beispiel laden oder die klar beschrifteten Felder für das eigene Szenario ausfüllen.
- Lokal prüfen und Kennzahlen, Warnungen sowie Korrekturen gemeinsam auswerten.
- Ergebnis in der Zielumgebung bestätigen und Annahmen dokumentieren.
prüfen, dass die erste Wartezeit Retry-After nicht unterschreitet, die Obergrenze hält und dieselbe Eingabe denselben Jitter liefert
Der Plan sendet keine Anfrage und beweist keine Idempotenz. Vor automatischen POST-/PATCH-Retries Idempotenzschlüssel, Serververtrag und reale Uhrabweichung prüfen.
Geeignete Anwendungen
- API-Client-Verhalten planen
- 429-Lasttests dokumentieren
- 503-Wiederanlauf planen
Nachvollziehbares Praxisbeispiel
Praxisszenario: API-Client-Verhalten planen. Retry-Regeln für 429/503, exponentielles Backoff, Jitter und Obergrenzen als Zeitplan darstellen.
GET, 429, Retry-After 8 Sekunden, 5 Versuche, 500 ms Basis, 30.000 ms Obergrenze und 20 % Jitter eingeben; danach POST wählen und Warnung vergleichen.
Abnahmenachweis: prüfen, dass die erste Wartezeit Retry-After nicht unterschreitet, die Obergrenze hält und dieselbe Eingabe denselben Jitter liefert. Kennzahlen und Warnungen der Ergebniskarte zusammen mit dem Testbeispiel aufbewahren.
In diesem Zustand nicht veröffentlichen: Der Plan sendet keine Anfrage und beweist keine Idempotenz. Vor automatischen POST-/PATCH-Retries Idempotenzschlüssel, Serververtrag und reale Uhrabweichung prüfen.
ARBEITSABLAUF VERTIEFEN
Ratgeber zu diesem Werkzeug
Zuverlässige API-Retries und Webhooks: Von 429 zum Idempotenznachweis
Retry-After, exponentielles Backoff, Jitter, Zustell-ID und Reihenfolge in einem testbaren Recovery-Vertrag verbinden.
Ratgeber lesen →API-Fehler-, Quoten- und Redirect-Verträge gemeinsam gestalten
Fehlerumschlag, Backoff, Kapazitätsgrenzen und URL-Übergänge ebenso wie Erfolg als versioniertes Produktverhalten behandeln.
Ratgeber lesen →ÜBER DIESES WERKZEUG
Häufig gestellte Fragen
Welche Eingabe akzeptiert Retry-After- und Backoff-Planer?+
HTTP-Methode, 429- oder 503-Antwort, Retry-After-Wert, Versuchszahl, Basisverzögerung, Obergrenze und Jitter-Prozent GET, 429, Retry-After 8 Sekunden, 5 Versuche, 500 ms Basis, 30.000 ms Obergrenze und 20 % Jitter eingeben; danach POST wählen und Warnung vergleichen.
Was liefert Retry-After- und Backoff-Planer?+
einen Zeitplan mit Versuchsnummer, Wartezeit, frühestem Retry-Zeitpunkt und Warnung bei unsicherer Methode Abnahmenachweis: prüfen, dass die erste Wartezeit Retry-After nicht unterschreitet, die Obergrenze hält und dieselbe Eingabe denselben Jitter liefert. Kennzahlen und Warnungen der Ergebniskarte zusammen mit dem Testbeispiel aufbewahren.
Wie prüfe ich die Ausgabe von Retry-After- und Backoff-Planer?+
prüfen, dass die erste Wartezeit Retry-After nicht unterschreitet, die Obergrenze hält und dieselbe Eingabe denselben Jitter liefert In diesem Zustand nicht veröffentlichen: Der Plan sendet keine Anfrage und beweist keine Idempotenz. Vor automatischen POST-/PATCH-Retries Idempotenzschlüssel, Serververtrag und reale Uhrabweichung prüfen.
Sendet oder speichert Retry-After- und Backoff-Planer Eingaben auf einem Server?+
Werkzeugeingaben werden im aktiven Tab verarbeitet. Speichern in der Workstation oder Übergabe an ein anderes Werkzeug erfolgt nach eigener Auswahl. Browser-Erweiterungen und gemeinsam genutzte Geräte gesondert prüfen; die Datenschutzseite erklärt Werbung und Netzwerkverbindungen.