Errores comunes al desplegar n8n en producción (2026)
Incidentes reales que aparecen tras el go-live de n8n en entornos B2B de España y la UE: proxy HTTPS mal alineao, secretos ausentes, volúmenes efímeros, webhooks inaccesibles desde fuera, colas saturadas, fugas de memoria y alertas que llegan cuando ventas ya ha perdido leads. Cómo detectarlos, corregirlos y cerrar la brecha entre funciona en mi portátil y producción estable.
El viernes la demo arranca sin errores; el lunes comercial reporta que el formulario envía pero el CRM no recibe nada. No es un bug del nodo HubSpot: es la brecha entre prueba y una instancia expuesta con tráfico real, certificados renovables y datos sujetos al RGPD. Aquí van los fallos que repetimos en despliegues self-hosted europeos, qué se rompe cuando el tráfico deja de ser simulado.
El vídeo repasa señales de alarma en logs, comprobaciones de proxy y el orden de diagnóstico que conviene seguir antes de tocar workflows en caliente.
Transcripción del vídeo
Cuando llevas n8n a producción, el fallo más silencioso no es un nodo mal configurado: es descubrir días después que un workflow se rompió y nadie se enteró. Por defecto, n8n registra la ejecución fallida en el historial, pero no avisa por correo, Slack ni Telegram. En entornos B2B donde un flujo alimenta el CRM, dispara correos de seguimiento o sincroniza leads desde formularios, esa ausencia de alertas convierte un error técnico en pérdida comercial.
La solución recomendada es un workflow centralizado de gestión de errores. Se construye con el disparador nativo Error Trigger, que se activa cuando cualquier otro flujo de la instancia falla. Ese disparador expone datos útiles: nombre del workflow, identificador interno, mensaje de error, nodo que provocó la caída y enlace directo a la ejecución concreta. Con esa información puedes notificar al equipo por el canal que ya uséis en operaciones.
Un patrón habitual combina Telegram y correo electrónico. Telegram resulta práctico para equipos pequeños: el mensaje llega al móvil, se puede reaccionar con un emoji para marcar visto o resuelto, y varios responsables comparten el mismo hilo sin duplicar tickets. El correo sirve como respaldo o para perfiles que no revisan mensajería instantánea. En ambos casos conviene formatear el cuerpo con campos dinámicos del error trigger: título del workflow, ID, descripción del fallo, nombre del nodo y URL de la ejecución.
Para montar el flujo desde cero, crea un workflow nuevo —por ejemplo, llamado "error-handler"— y añade el nodo Error Trigger como único disparador. Conecta después un nodo de Telegram (Send Message) o de SMTP/Gmail (Send Email). Antes de publicar, ejecuta una prueba simulada: en versiones recientes de n8n puedes lanzar una ejecución de test del propio error workflow para verificar plantilla y credenciales. Recuerda activar el workflow; un handler inactivo no recibirá eventos.
El paso que muchos olvidan es enlazar cada workflow productivo con ese handler. En la configuración del flujo (Settings), el campo Error Workflow debe apuntar al workflow de errores que acabas de publicar. Esa asignación no es global automática: hay que repetirla en cada automatización crítica o automatizar el proceso con scripts de la API si gestionas decenas de flujos. Sin ese enlace, el handler existe pero nunca se dispara.
En la plantilla de notificación, incluye siempre contexto accionable. Un mensaje que dice solo error en workflow obliga a abrir n8n, buscar entre cientos de ejecuciones y adivinar cuál falló. Mejor algo del estilo: Fallo en [nombre] · Nodo: [nodo] · ID ejecución: [id] · Ver log: [url]. Si operáis en Europa y tratáis datos personales, evita pegar payloads completos con emails o teléfonos en el canal; resume el tipo de dato afectado y enlaza al log interno con acceso restringido.
Para correo HTML, los saltos de línea planos no se renderizan bien en clientes de escritorio. Usa etiquetas <br> o un bloque HTML mínimo. Telegram acepta Markdown limitado; prueba el formato en un entorno de staging antes de confiar en producción. Si prefieres Slack o un sistema de incidencias (Jira, Linear, PagerDuty), el mismo error trigger alimenta un webhook HTTP con JSON estructurado.
Más allá de la notificación, define una rutina operativa: quién responde en horario laborario Europe/Madrid, qué flujos son críticos (SLA de respuesta en minutos) y cuáles pueden esperar al día siguiente. Clasifica workflows por impacto: sincronización CRM, facturación, alertas de leads calientes frente a informes semanales. No todos merecen la misma urgencia ni el mismo canal.
Otros errores frecuentes al desplegar n8n en producción van de la mano con la alerta. Publicar workflows sin activarlos, dejar credenciales de prueba, no fijar zona horaria del servidor (Europe/Madrid en VPS europeos), olvidar HTTPS en el webhook público o no limitar reintentos en nodos HTTP que pueden amplificar un fallo externo. Versiona cambios antes de tocar flujos que ya mueven datos reales y documenta qué handler de errores cubre cada instalación.
En self-hosted, revisa también rotación de logs y espacio en disco: una base de ejecuciones hinchada ralentiza la interfaz y complica el diagnóstico. Programa limpieza de ejecuciones antiguas según tu política de retención y RGPD. En n8n Cloud, vigila límites de ejecuciones concurrentes del plan; un pico de tráfico puede encolar fallos que el handler reportará en ráfaga.
Implementar un sistema de alertas de errores lleva menos de una hora y evita horas de caza manual cuando un formulario deja de crear leads en HubSpot o Pipedrive un viernes por la tarde. Es una de las primeras piezas que debería existir en cualquier instancia n8n usada para ventas B2B, junto con backups de credenciales cifradas y un checklist de seguridad antes de exponer webhooks a internet.
Aviso educativo: este contenido tiene fines informativos sobre automatización y operaciones técnicas. No constituye asesoramiento legal, fiscal ni financiero. Evalúa tu stack, contratos con proveedores y obligaciones RGPD con apoyo profesional antes de desplegar en producción.
Por qué falla n8n después del go-live
En staging probáis con datos inventados y sin proveedores externos golpeando URLs. Producción añade latencia, payloads grandes, reintentos de SaaS y ventanas de mantenimiento no planificadas. n8n asume URL pública conocida, OAuth alineao con el callback registrado en cada SaaS y almacenamiento que sobrevive a docker restart. Cuando alguna pieza falta, los síntomas aparecen días después del anuncio interno de ya está en producción.
El patrón más costoso: validar flujos en la UI sin validar infraestructura. Un workflow de leads puede ejecutarse a mano y crear el contacto en Pipedrive; activao por webhook falla en silencio porque la URL usa http://localhost:5678. RevOps lo descubre cuando cae la conversión. Confirma dominio, TLS, persistencia y variables antes de abrir tickets; la guía de instalación de n8n con Docker en VPS cubre el compose que este artículo da por desplegado, no endurecido.
Quien migró desde n8n Cloud espera autoescalado; en un VPS de 2 GB hay techo real. Repasa self-hosted frente a n8n Cloud para no asumir SLAs que solo existen en la nube del vendor.
Proxy y HTTPS mal configuraos
n8n detrás de Nginx o Traefik sin X-Forwarded-Proto y X-Forwarded-Host cree que opera en HTTP interno. La UI carga, pero OAuth redirige a esquemas mixtos y los webhooks apuntan a puertos no expuestos. Síntoma: bucle de login o Cannot GET /rest/oauth2-credential/callback tras autorizar HubSpot.
Configura N8N_PROTOCOL=https, N8N_HOST=automations.tudominio.es y cabeceras forwarded en el proxy, incluyendo proxy_set_header Host $host;. Comprueba con curl -I https://automations.tudominio.es/healthz respuesta 200 sin redirecciones HTTP/HTTPS. Certificados Let's Encrypt caducados imitan proxy mal configurao: integraciones que funcionaban ayer dejan de autenticarse; automatiza renovación y alerta 14 días antes. Con WAF corporativo en la UE, verifica que /webhook/ y /webhook-test/ no queden bloqueadas por reglas anti-bot, un 403 intermitente del proveedor SaaS se reporta en ventas como CRM desincronizado.
Variables y secretos incompletos
Hardcodear API keys en nodos Code funciona en demo y filtra a historial de ejecuciones y backups. Usad credenciales nativas y {{ $env.NOMBRE }} para valores transversales. Si N8N_ENCRYPTION_KEY cambia entre reinicios, OAuth queda ilegible; fijad clave en gestor de secretos. WEBHOOK_URL con esquema y dominio públicos evita URLs internas en pipeline comercial.
Credenciales de sandbox copiadas a producción crean oportunidades en portal de prueba invisible para ventas. Audita cada credencial antes del cutover; el artículo sobre diseño de flujos orientados a ventas B2B ayuda a separar nomenclatura por entorno desde el diseño.
Datos que se pierden al reiniciar
Imagen latest sin volumen nombrado borra workflows tras actualizar el VPS. /home/node/.n8n debe persistir o externalizarse a Postgres para metadatos y ejecuciones. Señal de alarma: instancia vacía tras docker compose pull, historial de ejecuciones desaparecido o scripts de CI con down -v. Backups nocturnos deben incluir volumen, volcado de base de datos y clave de cifrado, restaurar solo la imagen no responde ante auditoría RGPD sobre leads procesados.
SQLite aguanta equipos pequeños; miles de filas hacia CRM o hojas de cálculo piden Postgres. Si los informes dependen de agregaciones periódicas, revisa cómo el flujo de reporting comercial con Google Sheets escribe filas: un lock se manifiesta como timeout en nodos sanos.
Webhooks que no llegan desde fuera
Workflow activo y URL de producción visible, pero Typeform, Calendly o tu backend reciben timeout o 404. Causas: firewall sin 443 hacia el proxy, DNS obsoleto o mezcla de URL test/producción, solo la segunda recibe tráfico con el workflow publicado. Probáis con curl -X POST desde fuera de la VPC, no desde el propio servidor; un client_max_body_size bajo en Nginx devuelve 413 sin que n8n registre el intento.
Para formularios que crean oportunidades en CRM, cruzad la config con la guía de automatización de leads desde formulario hacia CRM: muchos incidentes son desalineación entre la URL del frontend y la que n8n expone tras el proxy. Para SaaS bidireccional, el material sobre webhooks en entornos comerciales B2B cubre firmas y reintentos que producción exige.
Memoria, colas y ejecuciones colgadas
En modo regular, workflows comparten proceso con la UI. Decenas de ejecuciones concurrentes, sync nocturno de CRM, enriquecimiento de listas, informes a Sheets, disparan OOM y dejan ejecuciones running eternamente mientras la UI no guarda cambios. Activa EXECUTIONS_MODE=queue con Redis y workers dedicados; separáis ingesta de procesamiento pesado. Limita concurrencia según RAM: en VPS de 4 GB, 10 a 15 ejecuciones simultáneas con nodos HTTP es un techo prudente.
Bucles sobre miles de contactos agotan memoria; usa Split In Batches. En self-hosted el techo lo ponéis vosotros; la comparativa n8n frente a Make para equipos B2B contextualiza cuándo compensa operar infraestructura propia frente a delegarla.
Monitorización que llega tarde
Healthcheck 200 no garantiza que el flujo de asignación de leads funcione. Equipos que monitorizan solo ¿responde el puerto? descubren fallos cuando comercial escala a dirección. Definid SLOs por workflow crítico: tasa de éxito > 99 % en 24 h, latencia p95 bajo umbral y cero colas > cinco minutos. Como mínimo, un cron externo que consulte la API de ejecuciones fallidas y avise si un flujo de captura o sync CRM falla dos veces seguidas.
En la UE, retener payloads con PII indefinidamente viola minimización. Configura EXECUTIONS_DATA_PRUNE=true con plazos acordes con legal; monitoriza disco lleno con la misma urgencia que CPU, un volumen al 100 % corrompe SQLite bajo carga y detiene escrituras sin aviso previo en la UI.
Tabla síntoma causa remedio
Referencia rápida para triaje en turno de guardia o cuando RevOps escala un n8n roto sin detalle técnico. Comprueba las filas en orden antes de redeployar la imagen entera.
| Síntoma | Causa probable | Remedio rápido |
|---|---|---|
| OAuth falla tras login correcto | Proxy sin cabeceras forwarded; N8N_PROTOCOL=http | HTTPS en proxy; N8N_PROTOCOL=https; N8N_HOST con dominio público |
| Webhook URL muestra localhost | WEBHOOK_URL ausente o incorrecta | Definir WEBHOOK_URL=https://dominio/webhook/ y reiniciar |
| Credenciales ilegibles tras restart | N8N_ENCRYPTION_KEY cambió o no persiste | Clave fija en secret store; reautenticar OAuth afectados |
| Instancia vacía tras actualizar | Sin volumen persistente; down -v en script | Volumen en /home/node/.n8n; restaurar backup; eliminar -v |
| Proveedor externo timeout en POST | Firewall, DNS obsoleto o body size limit | Abrir 443; verificar DNS; subir client_max_body_size |
| Ejecuciones running infinitas | OOM kill; worker caído en modo cola | Subir RAM; activar queue+Redis; matar ejecuciones zombie vía API |
| UI lenta con picos de tráfico | Modo regular con alta concurrencia | EXECUTIONS_MODE=queue; workers separados; limitar concurrencia |
| Leads en sandbox, no en CRM prod | Credenciales de entorno de prueba copiadas | Auditar credenciales por workflow; separar instancias staging/prod |
| Disco al 100 % sin aviso | Historial de ejecuciones sin poda | EXECUTIONS_DATA_PRUNE; alertas de disco; migrar a Postgres |
¿Cómo encaja este flujo con el EU AI Act y el RGPD?
El Reglamento (UE) 2024/1689 (EU AI Act) ya está en vigor. Si tu equipo usa automatizaciones con nodos de IA en n8n (Gemini, OpenAI, Claude u otros), la empresa actúa como desplegadora (deployer): no hace falta haber creado el modelo. Desde el 2 de febrero de 2025 el Artículo 4 exige un nivel suficiente de alfabetización en IA para quien opera estos sistemas. En España, la supervisión se articula con la AESIA (IA) y la AEPD (RGPD).
El RGPD sigue aplicando a nombres, correos y cargos de Leads B2B: base jurídica, minimización y, si hay perfiles automatizados a escala, evaluación de impacto. AI Act y RGPD se acumulan. Preferid n8n self-hosted en VPS UE, zona Europe/Madrid, logs de ejecución y aprobación humana (human-in-the-loop) antes de acciones sensibles en el CRM.
Detalle de transparencia Logixb2b: Uso responsable de IA y Transparencia. Este apartado es informativo, no sustituye asesoramiento legal ni de un DPO.
Evalúa tus horas y riesgos con el Auditor de Eficiencia Operativa B2B.
Bonus checklist de producción
Usad este bloque en la checklist de release o en el ticket de paso a producción. Ningún ítem debería quedar sin marcar antes de anunciar la instancia a ventas.
CHECKLIST, n8n en producción (self-hosted UE)
Infraestructura y red
[ ] Dominio público con TLS válido y renovación automática
[ ] Proxy con X-Forwarded-Proto y X-Forwarded-Host
[ ] N8N_HOST, N8N_PROTOCOL=https, WEBHOOK_URL alineaos
[ ] Puertos 443 abiertos; rutas /webhook/ permitidas en WAF
[ ] Healthcheck externo (no solo desde el propio servidor)
Persistencia y secretos
[ ] Volumen persistente o Postgres para metadatos
[ ] N8N_ENCRYPTION_KEY fija en gestor de secretos
[ ] Backups probados con restauración documentaa
[ ] Sin API keys en nodos; credenciales por entorno
Ejecución y escala
[ ] EXECUTIONS_MODE=queue + Redis si >20 ejecuciones concurrentes
[ ] Límite de concurrencia acorde a RAM del VPS
[ ] Poda de ejecuciones y retención acordada con legal/RGPD
Workflows críticos
[ ] URLs de webhook verificaas con POST desde internet externo
[ ] OAuth reautenticao en producción (no credenciales sandbox)
[ ] Flujos de leads y CRM probados con payload real anonimizado
[ ] Runbook con contacto de escalado y versión de imagen
Monitorización
[ ] Alertas por tasa de fallos en workflows de captura/sync CRM
[ ] Alertas de disco, memoria y caducidad de certificado
[ ] Revisión semanal de ejecuciones fallidas (no solo uptime)Preguntas frecuentes
¿Por qué n8n funciona en local pero falla en producción?
En local suele faltar el proxy HTTPS con cabeceras X-Forwarded-Proto, el dominio público en N8N_HOST y WEBHOOK_URL, volúmenes persistentes montados y límites de memoria acordes al volumen de ejecuciones. El entorno de desarrollo tolera HTTP plano y rutas internas; producción exige URL canónicas, certificados válidos y secretos inyectados por variables de entorno, no hardcodeados en workflows.
¿Qué variables de entorno son imprescindibles en n8n self-hosted?
Como mínimo: N8N_HOST, N8N_PROTOCOL=https, WEBHOOK_URL con el dominio público, N8N_ENCRYPTION_KEY estable entre reinicios, credenciales de base de datos si usáis Postgres externo, y EXECUTIONS_MODE=queue con Redis si el volumen supera unas decenas de ejecuciones concurrentes. Sin WEBHOOK_URL correcta, los enlaces generados apuntan a localhost y los proveedores externos no pueden entregar eventos.
¿Cómo evito perder workflows al reiniciar el contenedor?
Monta un volumen persistente en /home/node/.n8n o migrad a Postgres para metadatos y ejecuciones. Verifica que docker compose down no elimina volúmenes nombrados y que los backups incluyen la base de datos y la clave de cifrado. Un reinicio sin volumen deja la instancia vacía aunque la imagen arranque sin errores aparentes.
¿Cuándo activar modo cola (queue) en n8n?
Activa EXECUTIONS_MODE=queue con Redis cuando ves ejecuciones en cola permanente, picos que bloquean la UI o reinicios del worker por OOM. En equipos comerciales con sincronización CRM cada pocos minutos y webhooks de formularios, el umbral suele estar entre 20 y 50 ejecuciones simultáneas según complejidad de los flujos.
¿Cómo monitorizar n8n en producción sin sorpresas?
Alerta sobre tasa de fallos por workflow, latencia de cola, uso de memoria del contenedor, espacio en disco de logs y caducidad de certificados TLS. Un healthcheck HTTP no basta: revisa ejecuciones fallidas en las últimas 24 horas y configura notificaciones cuando un flujo crítico, captura de leads, sync CRM, deje de completarse con éxito.