Cuando un webhook de n8n no funciona, casi siempre es por una de estas causas: la plataforma de origen apunta a la Test URL en lugar de la Production URL, el workflow no está publicado, el método o la ruta no coinciden, o n8n está detrás de un reverse proxy y registra una URL que no es accesible desde fuera. En n8n Cloud hay una más: si el webhook tarda más de 100 segundos en responder, la petición falla con un 524.
La parte que más confunde es que las ejecuciones de producción no aparecen en el editor, así que parece que “no llega nada” cuando en realidad sí llegó. Esta guía ordena el diagnóstico de lo más probable a lo menos probable, con la comprobación concreta para cada caso, y termina con lo que hay que añadir para que el siguiente fallo no pase días sin que nadie lo vea. Da por sabido cómo está montado n8n y cómo se lee una ejecución.
¿Qué diferencia hay entre Test URL y Production URL?
Cada nodo Webhook genera dos URL, y la mitad de los problemas vienen de mezclarlas. Según la documentación de problemas comunes del nodo Webhook (consultado en septiembre de 2026):
| Test URL | Production URL | |
|---|---|---|
| Cómo se activa | Pulsando Listen for test event y enviando un evento de prueba | Publicando el workflow |
| Cuánto tiempo escucha | 120 segundos | Hasta que despublicas el workflow |
| ¿Se ven los datos en el editor? | Sí | No: se consultan en la pestaña Executions |
La consecuencia práctica: si pegaste la Test URL en tu formulario, tu pasarela de pago o tu CRM, funcionará mientras tengas el editor abierto escuchando y dejará de funcionar en cuanto cierres la pestaña. Y si usas la Production URL, no busques los datos en el lienzo: abre Executions y selecciona la ejecución.
La ruta de la Production URL contiene /webhook/ y la de la Test URL /webhook-test/ en la configuración por defecto, así que basta con mirar la URL configurada en el origen para descartar esta causa.
¿Cómo diagnostico un webhook de n8n que no se ejecuta?
Sigue la tabla en orden. Cada fila se comprueba en minutos.
| Síntoma | Causa probable | Cómo comprobarlo | Solución |
|---|---|---|---|
| Funciona al probar, deja de funcionar después | El origen usa la Test URL | Mira la URL configurada en la plataforma que envía | Sustitúyela por la Production URL |
| La Production URL no responde o devuelve 404 | El workflow no está publicado, o la ruta o el método no coinciden | Estado del workflow y método HTTP configurado en el nodo | Publica el workflow; iguala método y ruta con lo que envía el origen |
| Aviso de que la ruta ya está en uso | Otro workflow publicado usa la misma ruta y método | Busca otros workflows con esa ruta | Despublica el conflictivo o cambia ruta o método |
| Llega un GET pero el nodo espera POST (o al revés) | El nodo acepta un solo método por defecto | Método del emisor frente al del nodo | Cambia el método o activa Allow Multiple HTTP Methods en Settings |
En self-hosted, la URL que muestra n8n usa localhost, el puerto 5678 o http |
n8n está detrás de un reverse proxy sin URL pública configurada | URL mostrada en el nodo frente a tu dominio real | Define N8N_WEBHOOK_URL con tu dominio y N8N_PROXY_HOPS=1 |
| Peticiones desde IP permitidas rechazadas | Reverse proxy delante de n8n | ¿Hay proxy entre internet y n8n? | Ajusta N8N_PROXY_HOPS al número de proxies |
| Error 524 en n8n Cloud | El webhook no responde en 100 segundos | Duración de las ejecuciones que fallan | Responde de inmediato y procesa después |
| Falla con envíos grandes o archivos | Supera el tamaño máximo de payload (16 MiB por defecto) | Tamaño de la petición | En self-hosted, N8N_PAYLOAD_SIZE_MAX; mejor aún, enviar un enlace al archivo |
| El origen dice “enviado” pero no hay ejecución | La petición no llega a n8n | Registro de entregas del emisor y logs del proxy | Revisa DNS, certificado y firewall; prueba con curl |
El caso del reverse proxy en n8n self-hosted
Si alojas n8n tú mismo detrás de Nginx, Traefik o similar, n8n construye la URL del webhook con su protocolo, host y puerto internos, que no son los que ve internet. La guía de webhooks detrás de un reverse proxy (consultado en septiembre de 2026) indica tres cosas:
- Definir
N8N_WEBHOOK_URLcon la URL pública, para que n8n muestre y registre la dirección correcta.WEBHOOK_URLsigue funcionando como alias, pero está marcada como obsoleta desde la versión 2.35.0. - Definir
N8N_PROXY_HOPS=1. - Que el último proxy reenvíe las cabeceras
X-Forwarded-For,X-Forwarded-HostyX-Forwarded-Proto.
export N8N_WEBHOOK_URL=https://n8n.tudominio.com/
export N8N_PROXY_HOPS=1Este fallo es especialmente traicionero con integraciones que registran el webhook automáticamente en el servicio externo: n8n registra una URL interna y el servicio nunca consigue entregar nada. Si estás montando o revisando tu instancia, lo cuento con más contexto en la guía de n8n self-hosted en producción.
El caso del 524 en n8n Cloud
n8n Cloud pasa por Cloudflare y, si el webhook no responde en 100 segundos, la petición falla con un 524. Ocurre cuando el nodo está configurado para responder al terminar el último nodo y el workflow hace algo lento: llamar a una IA, generar un documento o esperar a otra API.
El nodo Webhook tiene tres modos de respuesta: Immediately, When Last Node Finishes y Using ‘Respond to Webhook’ Node. Para procesos largos, la documentación propone responder enseguida y separar el trabajo: un webhook que inicia el proceso y contesta al momento, y otro que se consulta para conocer el estado y recoger el resultado.
¿Cómo pruebo el webhook sin depender de la plataforma de origen?
Con curl, desde tu ordenador. Así separas “n8n no recibe” de “el origen no envía”. La documentación oficial usa ejemplos como estos (sustituye la URL por la tuya y el método por el que tengas configurado):
# Petición sin parámetros
curl --request GET https://tu-n8n.com/webhook/ruta
# Petición con un parámetro en el cuerpo
curl --request POST https://tu-n8n.com/webhook/ruta --data 'key=value'Si curl llega y la plataforma no, el problema está en el origen: URL mal copiada, método distinto, autenticación o un envío que ni siquiera se dispara. Si curl tampoco llega, el problema está en n8n o en lo que tiene delante: publicación, ruta, proxy, DNS o certificado.
Con la Production URL, después de lanzar la petición, comprueba la pestaña Executions. Si la ejecución aparece, el webhook funciona y el fallo está más adelante en el workflow.
¿Por qué el workflow se ejecuta dos veces?
Porque los emisores de webhooks reintentan. Si tu endpoint tarda en responder o devuelve un error, el emisor vuelve a enviarlo, y algunos avisan de que un mismo evento puede llegar más de una vez aunque todo vaya bien:
- Stripe reintenta la entrega en modo live durante un máximo de tres días con retroceso exponencial y documenta que un endpoint puede recibir el mismo evento más de una vez. Recomienda registrar los identificadores de evento ya procesados (webhooks de Stripe, consultado en septiembre de 2026).
- Hotmart reintenta automáticamente las notificaciones con error hasta cinco veces o hasta recibir una respuesta correcta (webhook de Hotmart, consultado en septiembre de 2026).
En el foro oficial de n8n hay hilos abiertos justo con estos síntomas, tanto de webhooks que funcionan con la Test URL y no en producción como de ejecuciones duplicadas por webhook.
Borrar el contacto duplicado de hoy no resuelve nada. La solución es que el workflow sea idempotente: antes de crear un contacto, dar un acceso o registrar un pago, comprueba si ese identificador de evento o de pedido ya se procesó. Si varias ejecuciones pueden llegar a la vez, esa comprobación tiene que apoyarse en algo que garantice unicidad, como una restricción única en la base de datos, y no solo en una búsqueda previa.
¿Qué errores comunes conviene evitar?
- Dejar la Test URL en producción porque “funcionaba” durante la prueba.
- Buscar los datos de producción en el editor y concluir que no llega nada.
- Duplicar un workflow publicado y olvidar que el webhook de la copia comparte ruta y método.
- Poner un proceso largo antes de responder en n8n Cloud y encontrarse con 524 y reintentos del emisor.
- Actualizar el proxy o el dominio sin revisar
N8N_WEBHOOK_URL. - Arreglar el síntoma y no el riesgo: el webhook vuelve a funcionar, pero nadie recupera los eventos que se perdieron mientras fallaba ni se entera la próxima vez.
¿Cómo evito que el webhook vuelva a fallar sin que nadie lo vea?
Un webhook caído no genera errores en n8n: si no llega la petición, no hay ejecución que falle. Por eso hacen falta varias capas, que desarrollo en automatizaciones que fallan en silencio:
- Error workflow. Crea un workflow que empiece con el nodo Error Trigger (consultado en septiembre de 2026) y asígnalo en Settings > Error workflow del workflow crítico. Se ejecuta cuando ese workflow falla en una ejecución automática; no se dispara con ejecuciones manuales, así que no lo des por probado lanzándolo a mano.
- Idempotencia por identificador de evento, para que los reintentos del emisor no dupliquen nada.
- Heartbeat. Si un webhook recibe normalmente registros cada hora y lleva varias horas sin ejecuciones, alguien tiene que recibir un aviso. Es la única forma de detectar el webhook que ha dejado de llegar.
- Reconciliación. Compara cada día lo que registra el origen (pagos, formularios) con lo que llegó al destino.
- Dueño de la alerta. Una persona concreta, no un canal compartido que nadie mira.
Checklist para un webhook de n8n en producción
- El origen usa la Production URL, no la Test URL.
- El workflow está publicado y ningún otro usa la misma ruta y método.
- El método HTTP del nodo coincide con el del emisor.
- En self-hosted detrás de proxy,
N8N_WEBHOOK_URLyN8N_PROXY_HOPSestán definidos y las cabecerasX-Forwarded-*se reenvían. - El webhook responde rápido; los procesos largos van después de la respuesta.
- Hay una prueba con curl documentada para cada webhook crítico.
- El workflow comprueba el identificador del evento antes de crear, cobrar o dar acceso.
- Tiene asignado un error workflow con alerta a una persona concreta.
- Existe un aviso si el webhook lleva demasiado tiempo sin recibir nada.
- Se sabe cómo reenviar desde el origen los eventos perdidos mientras falló.
¿Cuándo conviene delegarlo?
Si es un webhook de un formulario secundario, esta guía debería bastar. Conviene que lo mire alguien con criterio de sistema cuando el webhook sostiene algo que cuesta dinero o clientes si falla: pagos, altas de alumnos, asignación de leads o registros de un lanzamiento; cuando la instancia de n8n es self-hosted y nadie tiene claro cómo está montada; o cuando el fallo ya ha pasado varias veces y cada arreglo es un parche.
En esos casos el trabajo no es “arreglar el webhook”, sino rehacer el flujo para que sea observable: idempotencia, logs por registro, alertas con dueño y reproceso de lo que se pierde. Es lo que hacemos en un Automation Sprint dentro del servicio de automatización de procesos, y si el origen del problema está en el servidor, el proxy o los backups, lo abordamos con infraestructura y DevOps. Para ver cómo encaja cada flujo en el conjunto de la operación, tienes la guía de sistemas para negocios digitales.
Si tienes un webhook crítico que falla de vez en cuando y nadie sabe por qué, cuéntame qué proceso os está frenando y lo revisamos.
Preguntas frecuentes
¿Qué diferencia hay entre la Test URL y la Production URL de un webhook de n8n?
La Test URL solo escucha durante 120 segundos después de pulsar Listen for test event y muestra los datos en el editor. La Production URL queda registrada cuando publicas el workflow y sigue activa hasta que lo despublicas, pero sus datos no aparecen en el editor, sino en la pestaña Executions.
¿Por qué el webhook funciona en pruebas y no en producción?
Las causas más habituales son que la plataforma de origen tiene configurada la Test URL, que el workflow no está publicado, que otro workflow publicado ya usa la misma ruta y método, o que n8n está detrás de un reverse proxy sin N8N_WEBHOOK_URL definida y registra una URL que no es accesible desde fuera.
¿Por qué no veo los datos de la ejecución en el editor de n8n?
Porque las ejecuciones que entran por la Production URL no se muestran en el lienzo del editor. Para ver qué recibió el webhook hay que abrir la pestaña Executions del workflow y seleccionar la ejecución concreta. Si allí tampoco aparece, la petición no llegó a n8n o no coincidía con la ruta y el método.
¿Por qué mi workflow de n8n se ejecuta dos veces con el mismo webhook?
Muchos emisores reintentan cuando no reciben respuesta a tiempo o reciben un error, y algunos pueden entregar el mismo evento más de una vez. Stripe, por ejemplo, documenta entregas duplicadas. La solución no es solo quitar el duplicado de hoy: el workflow tiene que comprobar el identificador del evento antes de crear o cobrar nada.
¿Qué significa el error 524 en un webhook de n8n Cloud?
n8n Cloud usa Cloudflare, y si el webhook no responde en 100 segundos la petición falla con un 524. Suele pasar cuando el webhook espera a que termine un proceso largo. Se resuelve respondiendo de inmediato y procesando después, o separando el trabajo en un webhook que inicia el proceso y otro que consulta su estado.
