Monitoreo de infraestructura con n8n, Uptime Kuma y Telegram

El problema

Cuando administras varios servicios en un servidor propio, una caída puede pasar horas sin que nadie se entere. Lo normal es enterarse cuando un usuario escribe para decir que el sitio no abre. Quería saberlo antes que nadie, sin tener que revisar paneles a mano.

La solución

Armé un sistema de monitoreo con alertas automáticas que corre en mi propio servidor en Oracle Cloud. Vigila de forma continua tres servicios: este portafolio en WordPress, la instancia de n8n y el propio Uptime Kuma. Cuando cualquiera de ellos cae, o vuelve a estar en línea, me llega un mensaje a Telegram en segundos.

Cómo funciona

1. Uptime Kuma revisa cada servicio cada 60 segundos.
2. Cuando un servicio cambia de estado (de activo a caído, o al revés), Uptime Kuma envía un webhook a n8n.
3. n8n recibe el aviso, le da formato al mensaje y lo reenvía.
4. Un bot de Telegram me lo entrega en el celular.

Además, Uptime Kuma publica una página de estado abierta al público, donde cualquiera puede ver en tiempo real si los servicios están operativos.

Prueba real, no simulada

Para validar el flujo completo detuve a propósito el contenedor de WordPress. Uptime Kuma detectó el error 502 que devolvía el reverse proxy y llegó la alerta de caída a Telegram. Al volver a levantar el contenedor llegó la alerta de recuperación con 200 OK, dos minutos después. Las capturas de esta página son de esa prueba.

Un hallazgo que el propio sistema me ayudó a encontrar

Días después, el monitor marcó caído el portafolio sin que yo hubiera tocado nada. Al investigar descubrí un bucle de redirecciones: el caché de Nginx había guardado una redirección 301 defectuosa y la servía a todos los visitantes durante 10 minutos, hasta que expiraba. Lo corregí configurando el caché para guardar solo respuestas correctas (200) y nunca redirecciones. Sin el monitoreo, esa falla intermitente habría pasado desapercibida.

Decisiones técnicas

• Ningún contenedor expone puertos a internet: todos escuchan solo en 127.0.0.1, y Nginx es la única puerta de entrada pública, con HTTPS de Let’s Encrypt.
• n8n y Uptime Kuma usan WebSockets, así que configuré Nginx para mantener esas conexiones abiertas a través del proxy.
• Antes de publicar el workflow en GitHub lo revisé y reemplacé por valores genéricos todo dato que identificara mi instalación real: el chat de Telegram, la ruta del webhook y el ID de la instancia. El token del bot nunca está en el archivo; n8n lo guarda cifrado aparte.
• El servidor tiene firewall (UFW), protección contra ataques de fuerza bruta (Fail2Ban) y copias de seguridad diarias en Oracle Object Storage.

Cómo lo construí

Lo desarrollé con Claude como asistente técnico. Yo ejecuté cada paso en el servidor, diagnostiqué los errores que fueron apareciendo (permisos de volúmenes, el bucle de caché, el formato de los mensajes) y verifiqué que cada pieza funcionara antes de pasar a la siguiente.

Próximas mejoras

• Personalizar el formato del mensaje de Telegram.
• Sumar nuevos servicios al monitoreo a medida que crezca la infraestructura.

Código y documentación

El workflow de n8n (listo para importar), las capturas y las instrucciones para replicarlo están en GitHub: https://github.com/alexcitos/monitoreo-n8n-kuma-telegram