Qué es
Una mesa de triaje gratuita para entregas de webhooks que fallaron. Lee un registro sencillo y lo convierte en una lista clara de casos, causas y próximos pasos.
Triaje de webhooks fallidos
Cada webhook fallido merece su autopsia.
Pega el registro de entregas de Stripe, GitHub, Shopify o de tu propia cola. Webhook Morgue etiqueta cada fallo con su causa, te dice cuáles se pueden reenviar sin riesgo y arma un plan de reintentos con esperas razonables.
Para quién es
Para desarrolladores e ingenieros de guardia que reciben webhooks de plataformas de pago, comercio o código y necesitan decidir rápido qué reintentar.
Qué resuelve
Los reintentos a ciegas. Reenviar un 401 o un 410 solo genera más fallos, mientras que un 500 o un tiempo agotado suele necesitar apenas un reintento tranquilo. Esta herramienta los distingue.
Expediente
Una entrega por línea. Separa el evento, el código de estado y una nota con una barra vertical, o pega líneas JSON.
Línea de ejemplo: invoice.paid | 500 | upstream timeout | 14:02
Todavía no hay casos
Carga el registro de prueba para ver una autopsia completa de ocho entregas, o pega el tuyo.
El registro se lee en tu navegador. No se sube nada.
Verificación de firma
La mayoría de los errores 401 vienen de una firma que no coincide. Pega el cuerpo original, el secreto y la cabecera de firma para ver si concuerdan.
Usa un secreto de prueba. La verificación ocurre en tu navegador y el secreto nunca sale de esta página.
HMAC SHA 256 calculado con la API Web Crypto en tu navegador.
Causas de la muerte
Qué suele significar cada fallo y qué hacer al respecto.
Tiempo agotado
Reenvía con esperas crecientes. Haz que el manejador responda en pocos segundos y deja el trabajo lento a una cola.
El receptor falló
Reenvía con esperas crecientes cuando el receptor vuelva a estar sano. Revisa su registro de errores para este evento.
Límite de peticiones
Espera el tiempo que pidió el receptor y luego reenvía despacio.
Firma o acceso rechazado
No reenvíes todavía. Revisa el secreto de firma en ambos lados y luego reenvía una vez.
El endpoint ya no existe
No reenvíes. Apunta el webhook al nuevo endpoint o elimina la suscripción.
Contenido rechazado
No reenvíes tal cual. Corrige el manejador o el esquema y luego reenvía una vez.
Redirigido
Un receptor no debería redirigir. Cambia la URL del webhook por la dirección final.
Entregado
Nada que hacer. Esta entrega llegó.
Cómo se usa
Exporta el registro
Copia las entregas fallidas desde el panel de tu proveedor o tu propia cola. Basta con el nombre del evento y el código de estado.
Haz la autopsia
Cada línea se convierte en un caso etiquetado con su causa de muerte y un siguiente paso claro.
Sigue el plan
Reenvía los casos seguros según el calendario sugerido, corrige el resto primero y comparte el informe con tu equipo.
Lo que no hace
- No se conecta a tu proveedor ni reenvía nada por ti. Te dice qué reenviar y cuándo.
- No puede ver dentro del receptor. Un 500 significa que tu código falló, y el registro por sí solo no dice por qué.
- Solo lee los formatos que ves aquí. Un registro poco común quizá necesite una limpieza rápida antes.
Preguntas
¿Mi registro se envía a algún sitio?
No. El análisis, el plan y la verificación de firma funcionan en tu navegador.
¿Por qué no reenviar todo?
Reenviar un 401, 404 o 422 vuelve a fallar igual y puede disparar alertas o bloqueos. Corrige la causa primero y luego reenvía una vez.
¿Por qué las esperas son desiguales?
Un pequeño desfase aleatorio, llamado jitter, evita que muchos reintentos golpeen a un servidor que se recupera en el mismo segundo.