Grafana y Prometheus son la solución estándar para monitorizar un homelab. Los tengo corriendo en Phatt y son brutales para métricas del sistema: CPU, RAM, disco, temperatura, lo que quieras. Pero hay una cosa que no hacen bien, o que al menos requieren más configuración de la que merece el problema: decirte si un servicio está caído desde fuera.
Grafana te dice que el contenedor de Gitea consume 200MB de RAM. Lo que no te dice fácilmente es “oye, Gitea no responde por HTTP”. Son dos problemas distintos: métricas de sistema versus disponibilidad de servicio.
Para lo segundo existe Uptime Kuma. Y es uno de esos proyectos que te instalan en 5 minutos y no vuelves a pensar en él, excepto cuando te llega una alerta de que algo se ha caído.
Qué es Uptime Kuma#
Uptime Kuma es una alternativa self-hosted a UptimeRobot. La diferencia clave: en vez de que un servicio externo compruebe tus endpoints, lo haces tú mismo desde dentro de tu red. Tienes control total, sin límites de monitores, sin cuenta de pago, sin enviar datos de tus servicios internos a terceros.
El proyecto lo mantiene louislam en GitHub y tiene más de 50.000 estrellas. No es un proyecto hobby abandonado, hay releases regulares y una comunidad activa.
Lo que puede monitorizar:
- HTTP/HTTPS: comprueba que un endpoint responde con el código correcto
- TCP: verifica que un puerto está escuchando
- Ping: comprueba conectividad básica
- DNS: verifica que un dominio resuelve correctamente
- Docker: comprueba el estado de un contenedor específico
- Keyword: busca un texto específico en la respuesta HTTP
- Push: monitorización inversa (tu servicio hace ping a Kuma)
Lo que más uso es HTTP y Docker. El modo Push es especialmente útil para cronjobs: si el script no hace ping a Kuma en el intervalo esperado, te alerta.
Instalación con Docker en Phatt#
Sin complicaciones. Un docker-compose.yml y listo:
| |
El volumen de Docker socket es opcional pero recomendable: permite monitorizar contenedores por nombre directamente.
| |
Accedes a http://phatt:3101, creas la cuenta de administrador (solo la primera vez), y ya estás dentro del panel.
Si tienes Traefik configurado, añades las etiquetas correspondientes y accedes por status.tudominio.com con HTTPS automático.
| |
Mis monitores en Phatt#
Tengo 18 monitores configurados. Los agrupo por tipo:
Servicios web principales:
- Gitea (HTTP, cada 60s)
- Grafana (HTTP, cada 60s)
- Immich (HTTP, cada 60s)
- n8n (HTTP, cada 120s)
- Vaultwarden (HTTP, cada 60s)
- Open WebUI (HTTP, cada 120s)
- Audiobookshelf (HTTP, cada 300s)
Infraestructura:
- Phatt (Ping, cada 30s)
- BigWhoop NAS (Ping, cada 60s)
- ZimaBoard 01, 02, 03 (Ping, cada 60s)
Docker containers críticos:
- Traefik (Docker, cada 30s)
- PostgreSQL principal (Docker, cada 60s)
- Redis (Docker, cada 60s)
Cronjobs:
- Backup nocturno de Gitea (Push, 25 horas de gracia)
- Backup de Vaultwarden (Push, 25 horas de gracia)
El intervalo de comprobación lo ajusto según criticidad. Traefik lo compruebo cada 30 segundos porque si cae, caen todos los servicios web. Audiobookshelf cada 5 minutos porque no pasa nada si está caído unos minutos.
Alertas por Telegram#
La configuración de alertas es donde Uptime Kuma brilla. Tiene integraciones con más de 90 sistemas: Telegram, Slack, Discord, email, webhooks, Gotify, ntfy, PagerDuty…
Yo uso Telegram. Es lo más cómodo porque tengo el móvil siempre encima y las notificaciones llegan instantáneamente.
Para configurarlo:
- Crea un bot con @BotFather en Telegram
- Guarda el token que te da
- Obtén tu Chat ID (habla con @userinfobot)
- En Uptime Kuma: Settings → Notifications → Add Notification
- Tipo: Telegram, rellena token y Chat ID
- Marca “Apply on all existing monitors” si quieres aplicarlo a todo
El mensaje que llega cuando algo cae es limpio y directo:
| |
Y cuando se recupera:
| |
En un año y medio he recibido unas 40 alertas reales. La mayoría han sido actualizaciones de contenedores que tardaban más de lo esperado en volver. Tres han sido cosas que no sabía que estaban caídas. Esas tres ya justifican tener Uptime Kuma.
Status page pública#
Uptime Kuma permite crear páginas de estado públicas, al estilo de las páginas de status de servicios SaaS. Puedes elegir qué monitores mostrar, personalizarlas con tu logo, y compartir la URL.
Para un homelab personal no es imprescindible, pero si tienes un servicio que usan otras personas (un Gitea compartido, una instancia de Immich familiar, cualquier cosa), tener una URL de status que puedas compartir cuando algo falla es mucho más elegante que decirle a alguien “es que el servidor no responde, espera”.
La mía está en status.midnightlab.build y muestra los servicios que comparto con familia. Cuando alguien me dice “Plex no va”, lo primero que hago es mirar ahí.
Monitorización Push para cronjobs#
Este modo es el que menos gente configura y el más útil si tienes scripts automatizados.
La lógica es inversa: en vez de que Kuma compruebe si tu servicio responde, tu servicio hace ping a Kuma para decirle que ha terminado bien. Si Kuma no recibe ese ping en el tiempo configurado, te alerta.
Ejemplo: tengo un script de backup que corre todas las noches a las 3:00. Si a las 4:15 Kuma no ha recibido el ping de ese script, me llega una alerta. Significa que el backup tardó más de lo normal o que falló silenciosamente.
La configuración es sencilla. En Uptime Kuma creas un monitor de tipo “Push” y te da una URL como esta:
| |
Al final de tu script, añades:
| |
Si el script falla antes de llegar a esa línea, Kuma no recibe el ping y te alerta. Simple y efectivo.
Puedes integrarlo también con n8n para hacer cosas más elaboradas cuando se recibe el evento de caída: crear una tarea en tu gestor de tareas, enviar un mensaje a un canal específico, lanzar un script de recuperación automática.
Uptime Kuma vs Grafana+Prometheus#
La pregunta obvia es: ¿necesito los dos?
Depende de lo que quieras. Son herramientas complementarias, no alternativas:
| Uptime Kuma | Grafana+Prometheus | |
|---|---|---|
| Qué mide | Disponibilidad de servicio | Métricas del sistema |
| Perspectiva | Externa (¿responde?) | Interna (¿cómo está?) |
| Configuración | 5 minutos | Horas |
| Alertas | Inmediatas, sencillas | Configurables, complejas |
| Histórico | Uptime % por período | Series temporales detalladas |
| Uso de recursos | Mínimo | Moderado |
Grafana te dice que el servidor tiene el 95% de RAM ocupada. Uptime Kuma te dice que Immich no responde. Son capas distintas de observabilidad.
Yo uso los dos. Uptime Kuma para la monitorización reactiva (¿está caído?), Grafana para la proactiva (¿está a punto de quedarse sin disco?).
Recursos del sistema#
Uptime Kuma es sorprendentemente ligero. En Phatt, con 18 monitores activos:
| |
No necesitas un servidor dedicado. Corre perfectamente en un ZimaBoard, en una Raspberry Pi 4, o en cualquier máquina que ya tengas encendida. De hecho, tiene sentido correrlo en una máquina diferente al servidor principal: si Phatt se cae, Uptime Kuma también se cae y no puede alertarte. En mi caso lo tengo en un ZimaBoard del cluster K3s precisamente por eso.
Conclusión#
Uptime Kuma resuelve un problema concreto: saber si tus servicios están respondiendo, desde fuera, sin complicaciones. No intenta ser Grafana ni Prometheus. No necesitas aprender PromQL ni configurar exporters. Lo instalas, añades tus servicios, configuras Telegram, y ya.
En mi homelab es una de esas herramientas que instalé casi sin pensar y que ahora no concibo no tener. Cada vez que me llega una alerta de que algo se ha caído antes de que yo me diera cuenta, me acuerdo de por qué merece estar ahí.
Si ya tienes Grafana y Prometheus para métricas y Traefik para el routing, Uptime Kuma es la pieza que faltaba para tener una observabilidad completa del homelab sin complicarte la vida.