Aller au contenu
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESFiles
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESFiles
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESFiles
SERVICESExec
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESFiles
SERVICESExec
POURQUOI HOODYHTTP-natif
Retour aux cas d'usage
CRON · FILES · EXEC

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

Pointe votre vrai webhook Stripe sur une URL hoody-files pendant trente minutes. Le dossier contient maintenant quatorze fichiers JSON — chaque payload qui a tapé la production, octet pour octet. Une entrée cron lance un script exec qui les POST à staging à 9h, lundi au vendredi. Le schedule expire samedi prochain et se supprime.

Lire l'API Cron

Capture une fois, persiste comme fichiers, replaye sur schedule

Tout le flux est trois URLs. Le trafic de production arrive sur l'URL de capture. Les fichiers atterrissent dans hoody-files. Le cron parcourt le dossier et POST les bodies à staging. Pas de broker, pas de queue, pas de service de replay — juste un dossier et un schedule.

PIPELINEpas de broker · pas de queue
01 · CAPTURE

Le webhook de production devient un PUT

Mettez l'URL de votre webhook Stripe / Intercom / GitHub sur un chemin hoody-files. Chaque event arrive comme un PUT et atterrit comme un fichier JSON nommé avec son timestamp. Le dossier est l'enregistrement.

02 · PERSIST

Un dossier par jour, addressable comme URL

Les fichiers persistent sur disque ; chaque fichier a sa propre URL. Browse le dossier dans un navigateur, list-le via l'API, ou shell dedans avec curl. L'enregistrement est un fait que vous pouvez cat, scp ou versionner.

03 · REPLAY

Une entrée cron parcourt le dossier

POST une entrée cron managée avec schedule 0 9 * * 1-5 et command bash /scripts/replay.sh /webhooks/2026-05-03. Le script liste le dossier et POST chaque fichier à staging dans l'ordre des timestamps.

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

Deux POSTs et un dossier

La capture est un PUT par event webhook. Le replay est un POST sur l'API cron. Hoody Files tient l'enregistrement ; Hoody Cron le parcourt sur un schedule ; hoody-exec lance le script bash qui fait les POSTs. Trois services, pas de glue entre.

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
programme le replay
POST · entrée cron
# one cron entry replays the morning at 9am, mon-fri
curl -X POST \
  https://cron.containers.hoody.com/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 le schedule. vous avez écrit une URL PUT dans la config webhook, et un POST dans l'API cron — c'est tout le test de charge.

Ce que ça donne qu'une fixture de load-test 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 vos suppositions

L'enregistrement capture le JSON exact que Stripe a envoyé — incluant chaque champ nullable, chaque type d'event inattendu, chaque format customer_id que vous avez oublié. votre handler rencontre les mêmes payloads qui l'ont fait échouer 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 users utilisent le système. Le handler testé voit la rush du matin contre les mêmes caches, les mêmes voisins cron, la même DB chargée.

RÉPÉTABILITÉ

Replay jusqu'à ce que le bug parte

Le dossier est immuable ; le cron tourne chaque jour ouvré jusqu'à expires_at. Si le handler casse encore au run de mardi, vous le répares et laisses le run de mercredi le prouver. Même input à chaque fois — le handler est la seule chose qui change.

Ce que le schedule promet

Les chiffres viennent de l'API Hoody Cron managed entries 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 qu'en 1985 programme 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 schedules de replay par environnement reste largement dans le budget.

  3. POST POUR CRÉER1

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

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

Trafic de production, enregistré une fois, replayé sur un schedule.

capturé · vendredi 08:00replayé · lundi au vendredi 09:00
À QUOI RESSEMBLAIT L'ANCIEN LOAD TESTscript 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 tapé la production · replayés par un schedule
Lire l'API Cron

Ce que ça remplace

Les outils standard pour replayer du trafic webhook — recorders, services de replay, mocks programmés. Chacun est un SaaS, un sidecar ou un script à babysitter. La paire hoody-files + hoody-cron n'est rien de tout ça.

  • Enregistrement de webhooks ngrokUn plan SaaS pour enregistrer des requêtes que vous pouviez écrire sur disque
  • Rejeu d'événements HookdeckUn service de routage d'events pour ce qui est juste des fichiers dans un dossier
  • scripts de replay maisonGlue que vous écrivez une fois et oublies comment programmer
  • Mocks programmés PostmanUn siège monitor pour tirer du HTTP sur votre propre staging
  • serveurs de mock dans les envs de testUn second backend à maintenir à côté du vrai
  • fuzzing webhook manuelvous avezsis dans un terminal à 9h, collant des payloads

Capturez le trafic du vendredi. Programmez le replay de la semaine suivante. Laissez l'entrée cron expirer quand l'expérience est finie.

Lire l'API Cron

Lis les autres