Ir al contenido
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoAutomatizar tareaParaDesarrolladores backendParaEquipos de desarrolloServiciosCronServiciosFilesServiciosExecPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoAutomatizar tareaParaDesarrolladores backendParaEquipos de desarrolloServiciosCronServiciosFilesServiciosExecPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoAutomatizar tareaParaDesarrolladores backendParaEquipos de desarrolloServiciosCronServiciosFilesServiciosExecPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoAutomatizar tareaParaDesarrolladores backendParaEquipos de desarrolloServiciosCronServiciosFilesServiciosExecPor qué HoodyHTTP nativo
Volver a casos de uso
use-cases / recurring-webhook-replay / hero
CRON · FILES · EXEC

Reproduce los webhooks de esta mañana mañana a la misma hora

Apunta tu webhook real de Stripe a una URL de hoody-files durante treinta minutos. La carpeta tiene ahora catorce archivos JSON — cada payload que golpeó producción, byte por byte. Una entrada de cron ejecuta un script exec que los manda por POST a staging a las 9, de lunes a viernes. El horario expira el sábado siguiente y se borra solo.

Lee la API de Cron
use-cases / recurring-webhook-replay / pipeline

Captura una vez, persiste como archivos, reproduce con un horario

Todo el flujo son tres URLs. El tráfico de producción llega a la URL de captura. Los archivos aterrizan en hoody-files. El cron recorre la carpeta y manda los cuerpos por POST a staging. No hay broker, ni cola, ni servicio de replay — solo un directorio y un horario.

PIPELINEsin broker · sin cola
01 · CAPTURA

El webhook de producción se vuelve un PUT

Pon tu URL de webhook de Stripe / Intercom / GitHub a una ruta de hoody-files. Cada evento llega como un PUT y aterriza como un archivo JSON nombrado con su marca de tiempo. El directorio es la grabación.

02 · PERSISTE

Una carpeta por día, direccionable como URL

Los archivos persisten en disco; cada archivo tiene su propia URL. Navega el directorio en un navegador, lístalo vía API, o entra con curl. La grabación es un hecho que puedes hacer cat, scp o versionar.

03 · REPRODUCE

Una entrada de cron recorre la carpeta

Haz POST de una entrada de cron gestionada con schedule 0 9 * * 1-5 y comando bash /scripts/replay.sh /webhooks/2026-05-03. El script lista el directorio y manda cada archivo por POST de vuelta a staging en orden de marca de tiempo.

Captura y reproducción son el mismo protocolo en días distintos. Lo que grabó los bytes es lo que los reproduce. No hay parser de JSONL, ni sidecar, ni formato de grabación que tengas que aprender — archivos en una carpeta, en orden temporal.

use-cases / recurring-webhook-replay / mechanism

Dos POSTs y una carpeta

La captura es un PUT por evento de webhook. La reproducción es un POST a la API de cron. Hoody Files guarda la grabación; Hoody Cron la recorre con un horario; hoody-exec ejecuta el script bash que hace los POSTs. Tres servicios, sin pegamento entre ellos.

stripe → hoody-files
PUT · captura
# 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
programa la reproducción
POST · entrada 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" }

El lado de captura corre una vez un viernes por la mañana. El lado de reproducción corre cada día laborable hasta el sábado siguiente, cuando el campo expires_at de la entrada de cron borra el horario. Escribiste una URL PUT en la configuración de tu webhook, y un POST en la API de cron — esa es toda la prueba de carga.

use-cases / recurring-webhook-replay / powers

Lo que esto te da que un fixture de prueba de carga no puede

El tráfico sintético es lo que tú imaginabas que era la petición. El tráfico capturado es lo que de verdad llegó. Mismos nombres de campo, mismos casos límite, mismas sorpresas.

FIDELIDAD

Formas de payload reales, no tu suposición

La grabación captura el JSON exacto que envió Stripe — incluyendo cada campo nullable, cada tipo de evento inesperado, cada formato de customer_id que olvidaste. Tu handler se enfrenta a los mismos payloads con los que falló ayer.

SINCRONIZACIÓN

Misma presión a la misma hora del día que producción

La expresión cron 0 9 * * 1-5 aterriza la reproducción a la hora a la que tus usuarios reales usan el sistema. El handler bajo prueba ve el rush de la mañana contra las mismas cachés, los mismos vecinos cron, la misma BD ruidosa.

REPETIBILIDAD

Reproduce hasta que el bug desaparezca

La carpeta es inmutable; el cron corre cada día laborable hasta expires_at. Si el handler aún se rompe en la ejecución del martes, lo arreglas y dejas que la del miércoles lo demuestre. Misma entrada cada vez — el handler es lo único que cambia.

use-cases / recurring-webhook-replay / capacity

Lo que el horario promete

Los números salen de la API de entradas gestionadas de Hoody Cron y de la especificación estándar de expresiones cron — no de benchmarks inventados.

  1. CAMPOS POR ENTRADA5

    Expresión cron estándar de 5 campos — minuto, hora, día del mes, mes, día de la semana. La misma sintaxis que usaste en 1985 todavía programa la reproducción en 2026.

  2. ENTRADAS POR PÁGINA200

    GET /users/[user]/entries pagina hasta 200 entradas gestionadas a la vez. Sesenta y tres horarios de reproducción por entorno entran de sobra.

  3. POST PARA CREAR1

    Crea la reproducción recurrente con un POST /users/me/entries — schedule, comando, expires_at. PATCH después para silenciarla; DELETE para retirarla; expires_at la retira por ti.

Límites según la API de Entradas Gestionadas de Hoody Cron: expresiones cron estándar de 5 campos más macros @daily / @hourly, paginación hasta 200 entradas por página, expires_at es opcional y auto-desactiva la entrada pasado el plazo.

use-cases / recurring-webhook-replay / punchline

Tráfico de producción, grabado una vez, reproducido con un horario.

capturado · viernes 08:00reproducido · de lunes a viernes 09:00
CÓMO SE VEÍA LA VIEJA PRUEBA DE CARGAscript k6 · faker · formas de payload imaginadastu suposición de lo que envía stripe · re-supuesta cada trimestre
CÓMO SE VE AHORAPUT files/webhooks/[day] · POST cron/entries 0 9 * * 1-5bytes reales que golpearon producción · reproducidos por un horario
Lee la API de Cron
use-cases / recurring-webhook-replay / replaces

Lo que esto reemplaza

Las herramientas estándar para reproducir tráfico de webhooks — grabadores, servicios de replay, mocks programados. Cada una es un SaaS, un sidecar o un script que hay que cuidar. La pareja hoody-files + hoody-cron no es ninguno.

  • grabación de webhooks de ngrokUn plan SaaS para grabar peticiones que podrías escribir en disco
  • replays de eventos de HookdeckUn servicio de enrutamiento de eventos para lo que son archivos en una carpeta
  • scripts propios de replayPegamento que escribes una vez y olvidas cómo programar
  • mocks programados de PostmanUn asiento de monitor para disparar HTTP a tu propio staging
  • servidores mock en entornos de pruebaUn segundo backend que mantener junto al real
  • fuzzing manual de webhooksTú sentado en una terminal a las 9, pegando payloads
use-cases / recurring-webhook-replay / cta

Captura el tráfico del viernes. Programa la reproducción de la próxima semana. Deja que la entrada de cron expire sola cuando el experimento termine.

Lee la API de Cron
use-cases / recurring-webhook-replay / related

Lee los otros