Webhooks
Des réessais de webhooks fiables, avec un runbook quand ils s'épuisent
Arrêtez de perdre des webhooks en échec. SteadyCron réessaie avec backoff exponentiel, journalise chaque tentative et intègre votre runbook dans l'alerte quand les réessais s'épuisent.
Le problème
Stripe et GitHub réessaient leurs webhooks pour vous. Presque rien d'autre ne le fait. Dès que c'est vous qui appelez un service interne instable, une API partenaire ou le microservice à moitié fini d'un collègue, un simple timeout signifie que l'appel a disparu — pas de réessai, pas de trace, pas d'alerte. Vous le découvrez quand quelqu'un remarque que l'effet attendu ne s'est jamais produit.
Comment SteadyCron le résout
- 1 Créez une tâche HTTP avec la méthode, les en-têtes et le corps dont votre webhook a besoin — y compris tout en-tête de signature ou jeton bearer.
- 2 Définissez un délai d'expiration et un nombre de réessais avec backoff exponentiel (et choisissez de réessayer sur timeout ou sur des codes de statut spécifiques), pour qu'un 502 ou un cold start lent ne fasse pas disparaître l'appel.
- 3 Chaque tentative est journalisée — code de statut, corps de la réponse, durée — donc « le webhook est-il vraiment arrivé ? » a une réponse, pas une supposition.
- 4 Si les réessais s'épuisent, SteadyCron vous alerte — et si vous avez défini une note de runbook sur la tâche, l'alerte l'intègre directement (Slack, Telegram, e-mail), pour que la solution soit là, pas enfouie dans une doc.
# SteadyCron réessaie ceci avec backoff, puis alerte (avec votre runbook) si ça n'arrive jamais :
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 |
Statut, planning et dernière exécution de chaque tâche — en un coup d’œil.
Ce que « réessais en tant que service » veut vraiment dire ici
SteadyCron ne fait pas tourner une file de messages générique. Il fait une chose bien : appeler un point de terminaison HTTP selon un planning ou un déclencheur, réessayer en cas d’échec avec backoff, et tenir un registre honnête de ce qui s’est passé. Pour des appels sortants ponctuels — relayer un webhook vers un service interne, relancer une intégration instable, déclencher une notification qui doit arriver — c’est exactement le bon outil :
- Backoff exponentiel, pas une boucle de réessai à plat — un 503 passager reçoit un délai croissant au lieu de marteler le service en aval.
- Réessais sélectifs — sur timeout, sur des codes de statut spécifiques
(par ex.
502,503,429), ou seulement sur des erreurs réseau. Vous décidez ce qui est « réessayable » pour votre point de terminaison. - Un vrai journal d’audit — chaque tentative est une ligne du journal d’exécution avec statut, durée et corps de réponse tronqué, donc les réessais apparaissent comme des tentatives distinctes et inspectables plutôt que de disparaître dans une boîte noire.
Quand les réessais sont épuisés, vous n’avez pas juste « échec »
Une dead letter queue au sens SQS rejoue les messages. SteadyCron n’essaie pas d’être ça — ce n’est pas un broker de messages. Ce qu’il fait à la place : s’assurer que les réessais épuisés ne restent jamais silencieux. Le journal d’exécution de la tâche garde chaque tentative et sa réponse, et une alerte se déclenche au moment où le dernier réessai échoue.
Cette alerte peut porter une note de
runbook que vous avez écrite en amont —
« ce webhook relaie vers billing-internal ; s’il est en panne, vérifier
d’abord #billing-incidents » — pour que la personne réveillée à 3 h du matin
n’ait pas à chercher le contexte.
Idéal pour
- Relayer un webhook tiers (Stripe, un prestataire de paiement, un outil de support) vers un service interne qui n’a pas sa propre logique de réessai.
- Déclencher une notification ou un effet de bord qui doit arriver — provisionner une ressource, lancer un build en aval, synchroniser un enregistrement avec un autre système.
- Remplacer une boucle de réessai artisanale dans le code applicatif, pour que
la logique de réessai survive à un déploiement et soit visible en un seul
endroit plutôt qu’éparpillée dans des blocs
try/catch.
Documentation associée
Ne l’apprenez plus à vos dépens
Commencez avec l’offre gratuite — sans carte bancaire.
Commencer gratuitement