Antes de Uptime Kuma, mi sistema de monitorización consistía en abrir el navegador, escribir la IP de cada servicio y ver si respondía. Funciona, pero está lejos de ser un sistema. Un día me enteré de que un servicio llevaba 14 horas caído porque nadie (yo incluido) lo había comprobado manualmente en ese tiempo.
Eso fue hace dos años. Desde entonces tengo Uptime Kuma corriendo en el homelab y me avisa antes de que yo me dé cuenta de que algo falla. Con cuarenta y tantos monitores configurados, es el servicio que más uso en el día a día aunque sea el que menos veo, precisamente porque cuando funciona bien no necesita atención.
Qué es Uptime Kuma#
Es una herramienta de monitorización self-hosted. La alternativa más conocida en el mundo de los servicios pagados es UptimeRobot, que funciona desde fuera de tu red. Uptime Kuma corre dentro de tu infraestructura, lo que tiene ventajas e inconvenientes que veremos después.
La interfaz es clara: cada servicio que monitorices aparece como una tarjeta con un indicador verde/rojo y su historial de disponibilidad. Puedes crear páginas de estado públicas para compartir con otros (útil si tienes servicios que usan otras personas). Tiene soporte para múltiples canales de notificación: Telegram, Discord, Slack, email, webhooks y bastantes más.
El proyecto lo mantiene principalmente Louis Lam y ha tenido un desarrollo muy activo desde que se publicó en 2021. La versión 2 lleva un tiempo en desarrollo con mejoras importantes en la arquitectura, pero la versión 1 (la estable actual) funciona sin problemas.
Por qué correr la monitorización dentro del homelab#
Esta es la pregunta que me hacen más cuando hablo de Uptime Kuma. Si el servidor donde corre Uptime Kuma se cae, también se cae la monitorización. No te enterarás de que el servidor está caído porque el servicio que te avisaría también está caído.
Eso es real y hay que tenerlo en cuenta. Mi solución es correrlo en un nodo diferente al que concentra el resto de servicios. En mi caso tengo un pequeño SBC que corre casi solo Uptime Kuma y algunos servicios ligeros. Si el servidor principal falla, Uptime Kuma sigue funcionando desde el SBC y me avisa.
Otra opción que usa mucha gente: correr Uptime Kuma en un VPS pequeño (5-6 euros al mes) separado del homelab principal. Así tienes monitorización externa independiente del hardware de casa.
Lo que Uptime Kuma no puede hacer (y UptimeRobot sí): comprobar si tu homelab es accesible desde Internet de verdad. Si tu fibra cae, Uptime Kuma no se entera porque también está detrás de esa misma fibra. Para eso, un segundo monitor externo (aunque sea el plan gratuito de UptimeRobot para los servicios públicos) tiene sentido como complemento.
Instalación con Docker#
La forma más rápida de instalar Uptime Kuma es con Docker. El contenedor oficial funciona bien y las actualizaciones son sencillas.
El docker-compose que uso:
| |
Con esto levanta en el puerto 3001. El primer acceso te pide crear el usuario administrador. Después ya tienes acceso a la interfaz.
Para acceder desde fuera de la red local, lo pongo detrás de Nginx Proxy Manager con un subdominio. Si quieres que la página de estado sea pública, ese subdominio necesita tener un certificado SSL válido.
Una cosa importante con los datos: la carpeta ./data que montas como volumen es donde Uptime Kuma guarda todo: configuración, historial de monitores, alertas. Haz backup de esa carpeta regularmente. Yo la incluyo en mi política de backup diario. Cuando tuve que migrar el servicio a otro servidor, fue tan sencillo como copiar esa carpeta y levantar el compose en la nueva máquina.
Tipos de monitor que uso más#
Uptime Kuma tiene varios tipos de monitor. Los que uso en el homelab:
HTTP(S). El más común. Comprueba que una URL devuelve un código HTTP correcto (200, 301, 302…). Lo uso para todos los servicios con interfaz web. Puedes configurar que el monitor también compruebe que la respuesta contiene un texto específico, útil para asegurarte de que el servicio está respondiendo de verdad y no solo devolviendo una página de error del proxy.
TCP Port. Comprueba que un puerto TCP está abierto y respondiendo. Lo uso para servicios que no tienen HTTP (bases de datos, servidores de juegos, servicios internos que hablan protocolos propios).
Ping. El más básico. Hace ping a una IP o hostname. Lo uso para nodos del cluster que no tienen servicios HTTP directamente expuestos, solo para saber si la máquina está encendida y respondiendo.
DNS. Comprueba que un nombre DNS resuelve al valor correcto. Útil para detectar si algo ha cambiado en tu configuración de DNS interno sin darte cuenta.
Docker Container. Se conecta al socket de Docker y comprueba el estado de un contenedor específico. No tengo que hacer HTTP al contenedor, solo pregunto a Docker si está running. Para contenedores que no exponen puertos pero que necesito que estén corriendo, es muy cómodo.
Cómo organizo los monitores#
Con cuarenta y tantos monitores, la organización es importante. Uptime Kuma tiene “grupos” que actúan como categorías. Los míos están organizados así:
Infraestructura. Nodos del cluster, servidores físicos, máquinas virtuales. Básicamente pings y checks TCP para saber si las máquinas están encendidas.
Servicios internos. Todo lo que corre en el homelab pero no está expuesto a Internet: Gitea, servicios de base de datos, APIs internas, etc.
Servicios expuestos. Los servicios que tienen URL pública. Aquí el check es HTTP con verificación de certificado SSL.
Backups. Este grupo es menos obvio. Tengo monitores de tipo “Push” para los scripts de backup: el script de backup hace un HTTP GET a la URL del monitor al terminar con éxito. Si el monitor no recibe ese GET en el tiempo esperado, me avisa. Es una forma de saber que los backups están corriendo sin montar una infraestructura de monitorización de backups aparte.
Dominios externos. Webs que no controlo pero me importa que estén disponibles (clientes, proveedores con APIs que uso). Si una API externa que uso en automatizaciones cae, mejor enterarme pronto.
Configuración de notificaciones#
Las notificaciones son la parte más importante. Un monitor que detecta fallos pero no avisa no sirve de mucho.
El canal que más uso es Telegram. La configuración es directa: necesitas un bot de Telegram (lo creas con BotFather en dos minutos), el token del bot y el chat ID donde quieres recibir los mensajes. En Uptime Kuma, en Configuración > Notificaciones, añades el canal y lo pruebas. Si llega el mensaje de prueba, está funcionando.
Lo que configuro en cada monitor:
Retries. Cuántas veces intenta Uptime Kuma antes de marcar el servicio como caído y enviar la notificación. Para servicios críticos, uso 1-2 retries. Para servicios menos críticos, 3-5 para evitar falsos positivos por microinterrupciones. El intervalo de reintento es configurable por separado.
Intervalo. Cada cuánto comprueba el servicio. Para servicios críticos, 60 segundos. Para cosas menos urgentes, 5 minutos o incluso más. Más frecuencia = más carga en el servidor del monitor, pero también detección más rápida de problemas.
Maintenance windows. Cuando hago mantenimiento en el homelab, activo la ventana de mantenimiento para los monitores afectados. Así no me llegan notificaciones de “servicio caído” mientras estoy actualizando o reiniciando cosas a propósito.
La página de estado#
Una de las funciones que más uso con servicios que comparten otros es la página de estado pública. Uptime Kuma genera una página estática con el estado actual de los monitores que quieras mostrar.
Puedes personalizar el nombre, el logo y el mensaje. Los usuarios pueden suscribirse para recibir notificaciones cuando haya cambios de estado. Los monitores que añades a la página pueden mostrar el historial completo o solo el estado actual.
Para el homelab personal, la página de estado no siempre tiene mucho sentido (¿quién la va a ver?). Pero si tienes un homelab que da servicio a familia, amigos o proyectos de comunidad, es una forma profesional de comunicar incidencias sin tener que responder mensajes uno a uno.
Hay un detalle que no está perfectamente documentado: la página de estado pública es accesible sin autenticación. Si tienes Uptime Kuma detrás de un proxy con autenticación, necesitas asegurarte de que la ruta /status/ está excluida de la autenticación para que sea accesible públicamente. En Nginx Proxy Manager, esto se hace con una regla de excepción en la configuración avanzada.
Problemas que he tenido#
El más frecuente: falsos positivos por timeout demasiado ajustado. El timeout por defecto es de 48 segundos, pero algunos de mis servicios más lentos (especialmente los que hacen operaciones pesadas al arrancar) pueden tardar más que eso en responder. Resultado: monitor marca el servicio como caído aunque está funcionando. La solución es obvia pero lleva un tiempo calibrar el timeout correcto para cada servicio.
Otro problema: la base de datos de SQLite que usa Uptime Kuma (por defecto) puede crecer bastante con el tiempo si tienes muchos monitores con intervalos cortos. El historial de cada ping se guarda. Uptime Kuma tiene una opción para configurar cuántos días de historial mantiene, pero está un poco escondida en la configuración. Yo lo tengo en 90 días, que me parece razonable para los análisis que hago.
Con la versión de Docker, las actualizaciones son sencillas: parar el contenedor, hacer docker pull louislam/uptime-kuma:1, volver a levantar. Los datos persisten en el volumen. En los dos años que llevo usándolo, ninguna actualización me ha roto la configuración.
Lo que más me ha aportado tenerlo#
La tranquilidad de saber que si algo falla, me enteraré. Parece básico, pero antes de tener monitorización pasaba tiempo con servicios caídos sin darme cuenta, o me enteraba porque algo que dependía de ese servicio fallaba de forma misteriosa.
El historial de disponibilidad también es útil. Cuando un servicio lleva semanas con microinterrupciones de un minuto a las 3 de la mañana, eso aparece en el historial y puedes investigar qué está pasando. Sin ese registro, esas caídas breves pasan completamente desapercibidas.
Para homelab con varios servicios, Uptime Kuma es de los primeros servicios que recomendaría instalar, no de los últimos. La tranquilidad que da saber que tienes alertas configuradas vale más que muchas cosas más llamativas.