Alertas con n8n: monitorización y notificaciones que nadie se pierde

Una importación de datos se interrumpe a las dos de la madrugada, la interfaz con el sistema de gestión de mercancías solo devuelve mensajes de error, y nadie lo nota hasta la mañana siguiente. El daño rara vez surge del error en sí, sino de las horas en las que nadie lo advierte. Justo ahí entran las alertas con n8n: detectar incidencias y avisar por canales cada vez más urgentes, hasta que alguien reacciona.

Una alerta con n8n se compone de tres partes: un disparador que detecta el error (Error Trigger, Schedule Trigger o Webhook), una lógica de comprobación que decide si se alerta y con qué urgencia, y nodos de notificación para correo, Microsoft Teams, SMS o llamada telefónica. Si nadie reacciona dentro de un tiempo definido, el flujo pasa al siguiente nivel de escalado.

Por qué las alertas son el caso de uso de n8n más subestimado

La mayoría de las empresas usa n8n para la sincronización de datos y la automatización de procesos, pero la monitorización es uno de los casos de uso con el beneficio más rápido. Los servicios de alerta especializados facturan por usuario y mes y suelen quedar sobredimensionados para un equipo pequeño. Con n8n utiliza una herramienta que muchas empresas ya operan de todos modos, y mantiene la lógica de alerta en casa: quién es notificado, cuándo y sobre qué está escrito en un flujo que usted mismo puede leer y modificar.

El patrón encaja en casi cualquier sistema con interfaz: tienda online, sistema de gestión de mercancías, servidor de copias de seguridad, formularios de sitio web. Encontrará más ejemplos prácticos en nuestros casos de uso.

Los componentes: disparador, lógica de comprobación, canales

Cada alerta en n8n comienza con uno de tres tipos de disparador, que determinan cómo se advierte un problema en primer lugar:

• Error Trigger: inicia un flujo de error propio en cuanto otro flujo de n8n falla. Se define en los ajustes del flujo supervisado como Error Workflow y recibe los detalles de la ejecución fallida.
• Schedule Trigger: se ejecuta según un intervalo o una expresión cron, por ejemplo cada cinco minutos, y comprueba activamente si un sistema responde, si existe una copia de seguridad o si se ha superado un umbral.
• Webhook: recibe mensajes desde fuera, por ejemplo de una monitorización de servidor o de una aplicación capaz de enviar alertas por sí misma.

Tras el disparador sigue la lógica de comprobación, casi siempre un nodo IF o Switch: ¿es el error crítico o solo un aviso? ¿Es horario laboral o fin de semana? Solo después vienen los canales. n8n trae nodos listos para correo, Microsoft Teams y Slack; los SMS y las llamadas telefónicas pasan por servicios como Twilio o sipgate mediante una API. Una alerta seria debe ir por un canal que también despierte de noche.

Cómo montamos y operamos estos flujos para las empresas se muestra en nuestra página de servicio sobre automatización con n8n.

Una cadena de escalado, paso a paso

Una cadena de escalado típica tiene tres niveles y en n8n solo necesita un único flujo. Nivel uno: el Error Trigger se dispara, el flujo formatea el mensaje de error y lo publica en un canal de Teams, junto con un enlace de confirmación. Ese enlace apunta a un webhook que marca el mensaje como asumido. Nivel dos: un nodo Wait pausa el flujo, por ejemplo 15 minutos. Si para entonces no se ha confirmado, un correo va a la jefatura de equipo, de nuevo con enlace de confirmación. Nivel tres: tras otros 15 minutos sin reacción, el flujo dispara un SMS o una llamada telefónica al servicio de guardia.

La confirmación es clave. Sin ella, o bien todo escala hasta la llamada, o bien la cadena se corta tras el primer mensaje y nadie sabe si alguien se está ocupando. Quién asumió y cuándo queda registrado en el protocolo de ejecución mediante el webhook de confirmación.

Autovigilancia: quién alerta cuando el propio n8n está caído

Una monitorización que no se vigila a sí misma tiene un punto ciego: si el servidor de n8n está caído, tampoco se dispara ningún Error Trigger. La solución es un heartbeat, en inglés también llamado dead man's switch. Un pequeño flujo con Schedule Trigger se registra cada pocos minutos en un servicio de comprobación externo como Healthchecks.io o un Uptime Kuma autoalojado. Si la señal de vida se detiene, el servicio externo da la alarma, con independencia de lo que le haya ocurrido a n8n. Así ambos sistemas se vigilan mutuamente.

Errores típicos en las alertas con n8n

Los errores más frecuentes en las alertas con n8n no son técnicos, sino conceptuales. Estos cinco los vemos una y otra vez en la práctica:

• Todo alerta: si cada menudencia dispara un mensaje, todos se insensibilizan y la única alerta importante se pierde. Primero priorizar, después notificar.
• Error Workflow no asignado: el flujo de error existe, pero no está definido como Error Workflow en los ajustes de los flujos supervisados. Entonces, en caso de error, no ocurre nada.
• Probado solo manualmente: según la documentación de n8n, el Error Trigger solo se ejecuta en ejecuciones automáticas, no en pruebas manuales. Quien solo prueba manualmente cree erróneamente que sus alertas funcionan.
• Un solo canal: si la alerta pasa exclusivamente por Teams, cae junto con él cuando Microsoft 365 tiene una incidencia. Al menos un canal debería ser independiente, por ejemplo el SMS.
• Sin autovigilancia: sin heartbeat, nadie nota cuando el propio vigilante falla.

A esto se suma un punto organizativo: una cadena de escalado necesita personas que descuelguen al final. Antes de construirla, aclare quién está de guardia. La tecnología es la parte más sencilla.

Preguntas frecuentes

¿Qué es el Error Trigger en n8n?

El Error Trigger es un nodo que inicia un flujo de error propio en cuanto un flujo vinculado con él falla. Recibe los detalles de la ejecución fallida, como el nombre del flujo y el mensaje de error, y se asigna en los ajustes del flujo supervisado bajo Error Workflow. Con el nodo Stop And Error se pueden además provocar errores propios.

¿Puede n8n llamar automáticamente cuando ocurre un error?

Sí, a través de servicios de telefonía con API como Twilio o sipgate. El flujo de n8n llama a la interfaz del proveedor y con ello dispara un SMS o una llamada de voz con un mensaje. Para alertas ocasionales esto solo supone unos céntimos de tarifas del proveedor.

¿Cómo se supervisa el propio n8n?

Con un heartbeat: un flujo con Schedule Trigger se registra a intervalos cortos en un servicio de comprobación externo como Healthchecks.io o Uptime Kuma. Si el registro se detiene, el servicio externo alerta. Así se advierte una caída del servidor de n8n aunque el propio n8n ya no pueda enviar nada.

¿Sustituye n8n a los servicios de alerta especializados como PagerDuty?

Para equipos pequeños con un panorama de sistemas manejable, casi siempre sí: niveles de escalado, confirmación y varios canales se pueden reproducir por completo en n8n. Quien deba gestionar planes de guardia complejos con rotaciones y decenas de participantes estará mejor servido con un servicio especializado.

¿Funciona también con un n8n autoalojado?

Sí, todos los componentes descritos también están disponibles en la variante autoalojada. Para las empresas que valoran la soberanía alemana de los datos, este es el camino habitual: los mensajes de error solo salen entonces de su propio entorno para el envío de la notificación.

Las alertas no son un proyecto de semanas. Un primer flujo de error con dos niveles de escalado está listo en pocas horas, y el heartbeat que lo acompaña el mismo día. En la próxima caída nocturna no se enterará por el cliente a las ocho de la mañana, sino que reaccionará usted mismo a las dos de la madrugada.