Alerta de errores n8n

Qué es y para qué sirve

Este recurso es un workflow de n8n que vigila las ejecuciones fallidas de tus automatizaciones en producción y avisa a un canal de Ops o RevOps en cuanto detecta errores, en lugar de esperar a que un comercial pregunte por qué no ha llegado ningún lead en todo el día.

A diferencia de un healthcheck que solo comprueba si el servicio web responde, este flujo mira dentro de n8n: el contenedor puede estar perfectamente arriba y aun así un workflow concreto falla por una credencial caducada, un cambio en la API del CRM o un dato mal formado que llega desde un formulario.

El propio flujo está pensado para ser barato de mantener: no añade dependencias nuevas más allá de la API que n8n ya expone de forma nativa, y su lógica cabe en cuatro bloques encadenados que cualquier persona del equipo técnico puede entender de un vistazo sin necesidad de documentación externa adicional.

Cuándo usarlo (y cuándo no)

Tiene sentido activarlo en cuanto tengas cualquier automatización que toque el embudo de ventas corriendo en producción: sincronización con el CRM, captura de leads desde formularios, notificaciones a Slack o generación de tareas comerciales. Cuantos más workflows dependan de servicios externos, APIs de terceros, webhooks, credenciales que caducan, más valor aporta esta capa de vigilancia, porque los fallos de ejecución son mucho más frecuentes que las caídas completas del servidor y suelen pasar completamente desapercibidos.

También conviene activarlo cuando varias personas distintas crean y modifican workflows sobre la misma instancia, porque en ese escenario es más fácil que un cambio introducido por una persona rompa silenciosamente una automatización que mantiene otra, sin que nadie se entere hasta que revisáis el pipeline semanas después.

No es imprescindible en entornos de desarrollo o pruebas con poco tráfico, donde revisar manualmente el historial de ejecuciones una vez al día ya resulta suficiente. Tampoco sustituye a una herramienta de observabilidad completa si necesitas trazas detalladas, métricas históricas o alertas multicanal avanzadas: este flujo es un complemento ligero y barato que cubre el caso más habitual, no un sistema de monitorización empresarial con dashboards.

Requisitos previos

Necesitas una instancia de n8n con la API pública habilitada y una API key generada desde Settings a API. Trata esa clave como un secreto: guárdala como credencial de tipo Header Auth dentro de n8n en lugar de pegarla en texto plano en el nodo HTTP Request, así evitas exponerla si alguien exporta el workflow para compartirlo o pedir ayuda en un foro público.

También necesitas un canal de Slack con un Incoming Webhook dedicado a incidencias técnicas o comerciales (Ops/RevOps), y una idea clara de la ventana de lookback que quieres usar: si el Schedule corre cada quince minutos, un lookbackMinutes de veinte da un pequeño margen de solapamiento sin duplicar avisos ni dejar huecos sin cubrir entre ejecuciones consecutivas.

Configuración paso a paso en n8n

Descarga el archivo JSON e impórtalo en n8n desde el menú ⋯ a Import from File. En el lienzo verás el Schedule cada quince minutos, el nodo Config, la llamada HTTP GET a la API de ejecuciones filtrando por status=error y el nodo IF que decide si hay que avisar a Slack o terminar en la rama OK, sin alerta.

Abre el nodo Config alerta errores y rellena n8nApiBase (la URL base de tu instancia), apiKey (idealmente como credencial Header Auth), slackWebhookUrl y lookbackMinutes. Guarda los cambios y ejecuta el Schedule una vez de forma manual: si no hay fallos recientes, el flujo debe seguir la rama sin alerta sin generar ningún mensaje en el canal.

Para validar la rama de alerta, provoca un error de prueba en otro workflow no crítico, por ejemplo, desactivando temporalmente una credencial, y vuelve a ejecutar el Schedule. Deberías recibir en Slack un mensaje con el número de ejecuciones fallidas, los nombres de los workflows afectados y la hora de la comprobación; corrige el error de prueba en cuanto confirmes que la alerta llega correctamente.

Errores comunes y buenas prácticas

El fallo más frecuente es descuadrar la ventana de lookback con la frecuencia del Schedule: si el flujo corre cada quince minutos pero el lookback es de diez, quedan huecos de cinco minutos sin cubrir donde un error podría pasar desapercibido. Ajusta siempre el lookback para que sea igual o ligeramente mayor que el intervalo del Schedule, así te aseguras de no perder ninguna ejecución fallida entre dos comprobaciones.

Otro error habitual es incluir demasiada información sensible en el mensaje de Slack: basta con el conteo de fallos, el nombre de los workflows y la hora, sin pegar datos personales de leads o clientes que pudieran aparecer en los mensajes de error técnicos. Define también quién es la persona responsable de reaccionar ante cada alerta, porque un aviso que nadie mira a tiempo no aporta ningún valor real al equipo comercial ni técnico.

Revisa también periódicamente qué workflows generan más fallos: si uno concreto aparece de forma repetida en las alertas, probablemente merece una revisión más profunda de su lógica en lugar de seguir recibiendo el mismo aviso semana tras semana sin actuar sobre la causa raíz.

Alternativas en Make y Zapier

Make no expone una API genérica de ejecuciones fallidas como n8n, así que el equivalente más práctico es activar el gestor de errores nativo de cada escenario y enrutarlo hacia el mismo canal de incidencias que usarías aquí; consulta la guía enlazada sobre errores comunes al desplegar n8n en producción para entender qué tipo de fallos conviene vigilar primero en tu caso.

En Zapier, la alternativa pasa por las alertas de fallo integradas de cada Zap, que puedes redirigir a Slack o a correo electrónico para que el equipo se entere sin depender de revisar el historial manualmente cada mañana antes de empezar la jornada comercial.

Importar, configurar y producción 24/7

En n8n: ⋯ → Import from File → el JSON de este recurso. El flujo llega inactive. Abre el sticky INSTRUCCIONES del lienzo y el nodo Config/Set: URLs, umbrales y placeholders. Enlaza credenciales reales (HTTP Header Auth, OAuth Google Sheets, Slack Incoming Webhook, CRM Private App) — nunca dejes tokens en el archivo versionado.

Prueba una ejecución Manual o un evento de test (formulario, webhook, cron forzado). Revisa CRM, Sheets o Slack. Solo entonces Active. Timezone del workflow: Europe/Madrid.

Para que corra solo hace falta n8n online. Self-hosted UE: VPS Hetzner/OVH/IONOS (o panel con Docker) → Ubuntu → Docker Compose (n8n + Postgres) → HTTPS con Caddy/Nginx → N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE=Europe/Madrid, N8N_ENCRYPTION_KEY. Alternativa: n8n Cloud (importas, conectas credenciales y Active; vigila límites). Make/Zapier: mismo mapa mental; este JSON es el esqueleto n8n.

EU AI Act y RGPD: qué es y por qué tu empresa debe aplicarlo

El Reglamento (UE) 2024/1689 (EU AI Act) ya está en vigor. Si tu empresa usa n8n con nodos de IA (Gemini, OpenAI, Claude, etc.) en ventas o operaciones, actuáis como desplegadores (deployers): no hace falta ser el fabricante del modelo. Desde el 2 de febrero de 2025 el Artículo 4 exige alfabetización en IA del personal que opera estos sistemas; en agosto de 2026 se refuerza la supervisión (AESIA en España) y la trazabilidad.

En paralelo, el RGPD (AEPD) aplica porque el flujo trata datos de contacto B2B. Base jurídica, minimización y, si hay perfiles automatizados a escala, evaluación de impacto. AI Act y RGPD se acumulan: un fallo puede implicar ambas autoridades.

Este recurso ayuda en la práctica: placeholders sin secretos, Europe/Madrid, opción self-hosted en VPS UE (soberanía de datos), registro de ejecuciones en n8n (logs) y espacio para human-in-the-loop (aprobación antes de acciones sensibles). Detalle: /uso-responsable-de-ia-y-transparencia. Texto informativo, no asesoramiento legal.