Webhooks
Zuverlässige Webhook-Wiederholungen, mit Runbook bei Erschöpfung
Verlieren Sie keine fehlgeschlagenen Webhooks mehr. SteadyCron wiederholt mit exponentiellem Backoff, protokolliert jeden Versuch und bettet Ihr Runbook im Alert ein, wenn die Wiederholungen ausgehen.
Das Problem
Stripe und GitHub wiederholen ihre Webhooks für Sie. Fast nichts anderes tut das. Sobald Sie selbst einen instabilen internen Dienst, eine Partner-API oder den halbfertigen Microservice eines Kollegen aufrufen, bedeutet ein einziger Timeout: Der Aufruf ist verloren — keine Wiederholung, kein Eintrag, kein Alert. Sie merken es erst, wenn jemand bemerkt, dass der Folgeeffekt nie eingetreten ist.
So löst SteadyCron das
- 1 Legen Sie einen HTTP-Job mit Methode, Headers und Body an, die Ihr Webhook braucht — inklusive Signatur-Headers oder Bearer-Token.
- 2 Setzen Sie einen Timeout und eine Wiederholungsanzahl mit exponentiellem Backoff (und wählen Sie, ob bei Timeout oder bestimmten Statuscodes wiederholt wird), damit ein 502 oder ein langsamer Cold-Start den Aufruf nicht verliert.
- 3 Jeder Versuch wird protokolliert — Statuscode, Response-Body, Dauer — sodass „Ist der Webhook wirklich angekommen?“ eine Antwort hat, keine Vermutung.
- 4 Sind die Wiederholungen erschöpft, alarmiert SteadyCron Sie — und wenn Sie eine Runbook-Notiz am Job hinterlegt haben, bettet der Alert sie direkt ein (Slack, Telegram, E-Mail), sodass die Lösung sofort da ist statt in einer Doku vergraben.
# SteadyCron wiederholt dies mit Backoff und alarmiert (mit Ihrem Runbook), wenn es nie ankommt:
POST https://internal.example.com/webhooks/order-shipped
Authorization: Bearer ${WEBHOOK_TOKEN}
Content-Type: application/json
Jobs
| weekly-digest-email | HTTP | 0 9 * * 1 | in 2 days | 3 days ago | ||
| nightly-db-backup | Heartbeat | 0 2 * * * | in 19 h | 5 h ago | ||
| stripe-reconciliation | HTTP | 0 */4 * * * | in 38 min | 3 h ago | ||
| cache-warmup | HTTP | */15 * * * * | in 11 min | now | ||
| search-index-sync | Heartbeat | */30 * * * * | in 6 min | 24 min ago |
| seed-test-data | HTTP | 0 4 * * * | in 14 h | 10 h ago | ||
| preview-env-cleanup | Heartbeat | 0 */6 * * * | in 2 h | 4 h ago | ||
| trial-expiry-sweep | HTTP | 0 6 * * * | — | yesterday |
Status, Zeitplan und letzter Lauf jedes Jobs — auf einen Blick.
Was „Wiederholungen als Service“ hier wirklich bedeutet
SteadyCron betreibt keine generische Message-Queue. Es macht eine Sache gut: einen HTTP-Endpunkt nach Zeitplan oder per Trigger aufrufen, ihn bei Fehler mit Backoff wiederholen und ein ehrliches Protokoll führen, was passiert ist. Für einmalige ausgehende Aufrufe — einen Webhook an einen internen Dienst weiterleiten, eine instabile Integration erneut antreiben, eine Benachrichtigung auslösen, die ankommen muss — ist das genau die Aufgabe:
- Exponentieller Backoff, keine flache Wiederholungsschleife — ein vorübergehendes 503 bekommt eine wachsende Verzögerung statt den nachgeschalteten Dienst zu bombardieren.
- Selektive Wiederholungen — bei Timeout, bei bestimmten Statuscodes
(z. B.
502,503,429) oder nur bei Netzwerkfehlern. Sie entscheiden, was für Ihren Endpunkt „wiederholbar“ ist. - Ein echtes Audit-Log — jeder Versuch ist eine Zeile im Ausführungsprotokoll mit Status, Dauer und gekürztem Response-Body, sodass Wiederholungen als separate, einsehbare Versuche erscheinen statt in einer Black Box zu verschwinden.
Wenn die Wiederholungen erschöpft sind, bekommen Sie nicht nur „fehlgeschlagen“
Eine Dead-Letter-Queue im SQS-Sinn spielt Nachrichten erneut ab. SteadyCron versucht nicht, das zu sein — es ist kein Message-Broker. Was es stattdessen tut: dafür sorgen, dass erschöpfte Wiederholungen niemals still bleiben. Das Ausführungsprotokoll des Jobs behält jeden Versuch und seine Antwort, und ein Alert feuert in dem Moment, in dem die letzte Wiederholung fehlschlägt.
Dieser Alert kann eine Runbook-Notiz
tragen, die Sie vorab geschrieben haben — „dieser Webhook leitet an
billing-internal weiter; wenn der down ist, zuerst in #billing-incidents
nachsehen“ — sodass die Person, die um 3 Uhr nachts gepiept wird, nicht erst
nach Kontext graben muss.
Gut geeignet für
- Das Weiterleiten eines Drittanbieter-Webhooks (Stripe, ein Zahlungsdienstleister, ein Support-Tool) an einen internen Dienst ohne eigene Wiederholungslogik.
- Das Auslösen einer Benachrichtigung oder eines Folgeeffekts, der ankommen muss — eine Ressource bereitstellen, einen nachgeschalteten Build anstoßen, einen Datensatz mit einem anderen System synchronisieren.
- Den Ersatz einer handgebauten Wiederholungsschleife im Anwendungscode, damit
die Wiederholungslogik ein Deploy überlebt und an einer Stelle sichtbar ist
statt über
try/catch-Blöcke verstreut.
Verwandte Dokumentation
Erfahren Sie es nicht erst im Ernstfall
Starten Sie mit dem kostenlosen Tarif — keine Kreditkarte erforderlich.
Kostenlos starten