Healthcheck n8n en Docker

Qué es este recurso y qué problema resuelve

Este recurso es un workflow de n8n listo para importar que comprueba, cada pocos minutos, si tu instancia de n8n desplegada en Docker sigue respondiendo.

La idea de fondo es sencilla pero muy rentable en equipos B2B que dependen de n8n para mover leads, avisar a ventas o sincronizar el CRM: un contenedor que se reinicia solo, un fallo de red o un despliegue mal hecho puede dejar automatizaciones muertas durante horas sin que nadie lo note, hasta que un comercial pregunta por qué no ha entrado ningún lead en todo el día. Este healthcheck actúa como una capa de vigilancia barata que no requiere contratar una herramienta de monitorización externa.

Cuándo tiene sentido activarlo (y cuándo no)

Tiene sentido instalarlo en cuanto tengas cualquier automatización de negocio corriendo en producción sobre un n8n autoalojado en Docker o Docker Compose: sincronizaciones con el CRM, webhooks de formularios, alertas comerciales o integraciones con Slack y correo. Cuanto más dependa el equipo comercial de que esos flujos sigan vivos, más justificado está dedicar cinco minutos a montar este comprobador.

Si trabajas exclusivamente con n8n Cloud, el proveedor ya se encarga de la disponibilidad de la infraestructura y este recurso pierde parte de su sentido original, aunque puedes adaptarlo igualmente para vigilar workflows concretos que consideres críticos. Su valor principal está pensado para instalaciones self-hosted, donde tú eres la única persona responsable de que el contenedor siga en marcha.

Qué necesitas antes de importarlo

Necesitas una instancia de n8n en Docker o Docker Compose ya en marcha, con una dirección accesible por HTTPS que sirva como comprobación de salud: el propio /healthz si tu versión lo expone, o en su defecto la URL pública de inicio de sesión. También necesitas una segunda instancia de n8n, distinta e independiente, donde importar este flujo: si el comprobador vive en el mismo servidor que se cae, no podrá avisarte de nada cuando más falta hace.

Esa segunda instancia puede ser una cuenta gratuita de n8n Cloud, otro VPS o incluso otro contenedor en una máquina distinta.

Cómo funciona el flujo paso a paso

El workflow encadena cuatro piezas. Un nodo de horario dispara la ejecución cada cinco minutos, un valor pensado como equilibrio entre reactividad y ruido. Un nodo Config centraliza las variables que vas a rellenar en un único sitio, en vez de tener que buscar valores sueltos por todo el lienzo. Un nodo de petición HTTP llama a la dirección de salud y recoge el código de respuesta. Un nodo IF decide qué rama seguir según ese código.

Si la respuesta es correcta (código 200), el flujo termina sin generar ningún mensaje, precisamente para que el canal de Slack no se llene de confirmaciones inútiles que el equipo acabaría ignorando.

Configuración detallada en n8n

Descarga el archivo JSON del recurso e impórtalo en tu segunda instancia desde el menú ⋯ a Import from File. En el lienzo deberías ver los cuatro bloques descritos: horario, Config healthcheck, petición a la dirección de salud y aviso a Slack. Si falta alguno, actualiza n8n a una versión reciente e importa de nuevo, porque versiones antiguas a veces no reconocen ciertos nodos.

Abre el nodo Config healthcheck y rellena tres campos: n8nHealthUrl con la dirección completa que quieres comprobar, instanceLabel con un nombre corto y legible para identificar la instancia en los avisos, y slackWebhookUrl con la dirección de entrada de tu Incoming Webhook. Pulsa Execute step en el nodo de horario para lanzar una ejecución de prueba y confirma que la petición recibe un código correcto y que sigue la rama sin alerta.

A continuación, cambia temporalmente la URL por una incorrecta a propósito y vuelve a ejecutar: debería llegarte a Slack un mensaje completo con instancia, URL, código y hora. Cuando confirmes que todo funciona, restaura la dirección correcta, conecta el canal real del equipo y activa el interruptor Active del flujo.

Operación diaria, RGPD y alternativas en Make o Zapier

Anota siempre quién es la persona responsable de reaccionar cuando llegue una alerta, con un procedimiento mínimo: revisar docker compose ps en el servidor y mirar los logs del contenedor antes de reiniciar nada a ciegas. Si tu versión de n8n no expone /healthz, la URL pública de inicio de sesión es un sustituto razonable, aunque no valide el estado interno completo de la cola de ejecución. Ajusta la frecuencia si tienes procesos muy sensibles al tiempo, como webhooks de pago, bajando el intervalo a uno o dos minutos sin miedo, ya que el flujo es muy ligero.

Este workflow no maneja datos personales de clientes ni de leads, solo códigos de estado HTTP y metadatos técnicos, por lo que su impacto en materia de RGPD es prácticamente nulo; aun así, evita pegar tokens dentro del propio mensaje de Slack.

Errores típicos al ponerlo en marcha y cómo evitarlos

El error más frecuente es instalar el comprobador en el mismo servidor o el mismo Docker Compose que la instancia vigilada, de modo que cuando cae la producción, el propio vigilante cae con ella y nunca llega ninguna alerta; sepáralos siempre en máquinas o cuentas distintas desde el primer día.

También es común olvidar que un webhook de Slack puede caducar o desactivarse si se reconfigura la integración del canal, dejando el flujo activo pero sin capacidad real de avisar a nadie; conviene revisar cada cierto tiempo, por ejemplo una vez al trimestre, que el webhook sigue siendo válido enviando una alerta de prueba controlada. Por último, si tienes varios entornos (producción, staging, preproducción), evita mezclar sus alertas en el mismo canal sin distinguir claramente el nombre de la instancia, porque el equipo acabará ignorando avisos que en realidad sí son urgentes.

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.