Aller au contenu
TypeDéverrouilléÉtapeParcDifficultéModéréTravailAutomatiser une tâchePourDevs backendPourÉquipes de devServicesCronServicesFilesServicesExecPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeParcDifficultéModéréTravailAutomatiser une tâchePourDevs backendPourÉquipes de devServicesCronServicesFilesServicesExecPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeParcDifficultéModéréTravailAutomatiser une tâchePourDevs backendPourÉquipes de devServicesCronServicesFilesServicesExecPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeParcDifficultéModéréTravailAutomatiser une tâchePourDevs backendPourÉquipes de devServicesCronServicesFilesServicesExecPourquoi HoodyHTTP-natif
Retour aux cas d'utilisation
use-cases / recurring-webhook-replay / hero
CRON · FILES · EXEC

Rejouez les webhooks de ce matin à la même heure demain

Pointez votre vrai webhook Stripe vers une URL hoody-files pendant trente minutes. Le répertoire contient maintenant quatorze fichiers JSON — chaque payload qui a frappé la production, octet pour octet. Une seule entrée cron exécute un script exec qui les renvoie en POST sur la staging à 9h, du lundi au vendredi. La planification expire samedi prochain et se supprime elle-même.

Lire l'API Cron
use-cases / recurring-webhook-replay / pipeline

Capturez une fois, persistez sous forme de fichiers, rejouez sur planification

Tout le flux tient en trois URLs. Le trafic de production arrive sur l'URL de capture. Les fichiers atterrissent dans hoody-files. Cron parcourt le dossier et POSTe les corps vers la staging. Pas de broker, pas de file d'attente, pas de service de replay — seulement un répertoire et une planification.

PIPELINEpas de broker · pas de file d'attente
01 · CAPTURE

Le webhook de production devient un PUT

Réglez l'URL de votre webhook Stripe / Intercom / GitHub vers un chemin hoody-files. Chaque événement arrive sous forme de PUT et atterrit comme un fichier JSON nommé avec son horodatage. Le répertoire est l'enregistrement.

02 · PERSIST

Un dossier par jour, adressable comme URL

Les fichiers persistent sur disque ; chaque fichier a sa propre URL. Parcourez le répertoire dans un navigateur, listez-le via l'API, ou connectez-vous en shell avec curl. L'enregistrement est un fait que vous pouvez cat, scp ou versionner.

03 · REPLAY

Une entrée cron parcourt le dossier

POSTez une entrée cron managée avec la planification 0 9 * * 1-5 et la commande bash /scripts/replay.sh /webhooks/2026-05-03. Le script liste le répertoire et POSTe chaque fichier vers la staging dans l'ordre des horodatages.

Capture et replay sont le même protocole sur des jours différents. La chose qui a enregistré les octets est la chose qui les rejoue. Pas de parseur JSONL, pas de sidecar, pas de format d'enregistrement à apprendre — des fichiers dans un dossier, dans l'ordre temporel.

use-cases / recurring-webhook-replay / mechanism

Deux POSTs et un dossier

La capture, c'est un PUT par événement webhook. Le replay, c'est un POST vers l'API cron. Hoody Files détient l'enregistrement ; Hoody Cron le parcourt sur planification ; hoody-exec exécute le script bash qui fait les POSTs. Trois services, aucune glu entre eux.

stripe → hoody-files
PUT · capture
# point your real webhook at hoody-files
curl -X PUT \
  https://files.containers.hoody.com/webhooks/2026-05-03/stripe-08-15-22.json \
  --data-binary @-

# 30 minutes later, the directory holds 14 files
HTTP/1.1 201 Created
webhooks/2026-05-03/stripe-08-15-22.json
planifier le replay
POST · entrée cron
# one cron entry replays the morning at 9am, mon-fri
curl -X POST \
  https://cron.containers.hoody.com/api/v1/cron/users/me/entries \
  -d '["schedule":"0 9 * * 1-5","command":"bash /scripts/replay.sh /webhooks/2026-05-03","expires_at":"2026-05-10T09:00:00Z"]'

HTTP/1.1 201 Created
{ "id":"f0a8", "schedule":"0 9 * * 1-5", "expires_at":"2026-05-10T09:00:00Z" }

Le côté capture tourne une fois un vendredi matin. Le côté replay tourne chaque jour ouvré jusqu'à samedi prochain, où le champ expires_at de l'entrée cron supprime la planification. Vous avez écrit une URL PUT dans la config de votre webhook, et un POST dans l'API cron — c'est tout le test de charge.

use-cases / recurring-webhook-replay / powers

Ce que cela vous donne qu'un fixture de test de charge ne peut pas

Le trafic synthétique est ce que vous imaginiez que la requête ressemblait. Le trafic capturé est ce qui est réellement arrivé. Mêmes noms de champs, mêmes cas limites, mêmes surprises.

FIDÉLITÉ

Vraies formes de payload, pas votre supposition

L'enregistrement capture le JSON exact que Stripe a envoyé — y compris chaque champ nullable, chaque type d'événement inattendu, chaque format customer_id que vous avez oublié. Votre handler rencontre les mêmes payloads sur lesquels il a échoué hier.

TIMING

Même pression à la même heure que la production

L'expression cron 0 9 * * 1-5 fait atterrir le replay à l'heure où vos vrais utilisateurs utilisent réellement le système. Le handler testé voit l'affluence du matin contre les mêmes caches, les mêmes voisins cron, la même base de données bruyante.

RÉPÉTABILITÉ

Rejouez jusqu'à ce que le bug disparaisse

Le dossier est immuable ; le cron tourne chaque jour ouvré jusqu'à expires_at. Si le handler casse encore lors du run de mardi, vous le réparez et laissez celui de mercredi le prouver. Même entrée à chaque fois — le handler est la seule chose qui change.

use-cases / recurring-webhook-replay / capacity

Ce que la planification promet

Les chiffres viennent de l'API des entrées managées Hoody Cron et de la spec d'expression cron standard — pas de benchmarks inventés.

  1. CHAMPS PAR ENTRÉE5

    Expression cron standard à 5 champs — minute, heure, jour-du-mois, mois, jour-de-la-semaine. La même syntaxe que vous utilisiez en 1985 planifie encore le replay en 2026.

  2. ENTRÉES PAR PAGE200

    GET /users/[user]/entries pagine jusqu'à 200 entrées managées à la fois. Soixante-trois planifications de replay par environnement reste largement dans le budget.

  3. POST POUR CRÉER1

    Créez le replay récurrent avec un seul POST /users/me/entries — schedule, command, expires_at. PATCH plus tard pour le mettre en sourdine ; DELETE pour le retirer ; expires_at le retire pour vous.

Limites selon l'API Hoody Cron Managed Entries : expressions cron standard à 5 champs plus les macros @daily / @hourly, pagination jusqu'à 200 entrées par page, expires_at est optionnel et désactive automatiquement l'entrée passée la deadline.

use-cases / recurring-webhook-replay / punchline

Trafic de production, enregistré une fois, rejoué sur planification.

capturé · vendredi 08:00rejoué · du lundi au vendredi 09:00
À QUOI RESSEMBLAIT L'ANCIEN TEST DE CHARGEscript k6 · faker · formes de payload imaginéesvotre supposition de ce que stripe envoie · re-supposée chaque trimestre
À QUOI ÇA RESSEMBLE MAINTENANTPUT files/webhooks/[day] · POST cron/entries 0 9 * * 1-5vrais octets qui ont frappé la production · rejoués par une planification
Lire l'API Cron
use-cases / recurring-webhook-replay / replaces

Ce que cela remplace

Les outils standards pour rejouer le trafic webhook — enregistreurs, services de replay, mocks planifiés. Chacun est un SaaS, un sidecar ou un script à materner. La paire hoody-files + hoody-cron n'est rien de tout cela.

  • enregistrement de webhooks ngrokUn plan SaaS pour enregistrer des requêtes que vous pourriez écrire sur disque
  • replays d'événements HookdeckUn service de routage d'événements pour ce qui n'est que des fichiers dans un dossier
  • scripts de replay sur mesureDe la glu que vous écrivez une fois et oubliez comment planifier
  • mocks planifiés PostmanUn siège de monitor pour tirer du HTTP vers votre propre staging
  • serveurs de mock dans les envs de testUn second backend à maintenir aux côtés du vrai
  • fuzzing manuel de webhooksVous, assis dans un terminal à 9h, à coller des payloads
use-cases / recurring-webhook-replay / cta

Capturez le trafic de vendredi. Planifiez le replay de la semaine prochaine. Laissez l'entrée cron expirer d'elle-même quand l'expérience est terminée.

Lire l'API Cron
use-cases / recurring-webhook-replay / related

Découvrez les autres