Uptime Kuma es un monitor de código abierto y autoalojado para comprobaciones HTTP(S), TCP, ping, DNS, WebSocket y otras. En un VPS aparte, sigue comprobando cuando tu servidor de producción falla, en lugar de desaparecer con él.
Esta instalación de Uptime Kuma en un VPS despliega la v2 con Docker Compose, mantiene el puerto 3001 en loopback, añade HTTPS mediante Caddy, envía las alertas a Telegram, Discord y Slack, y publica una página de estado.
Requisitos previos y lo que necesitarás
- Un VPS con al menos 1 vCPU, 1 GB de RAM y 10 GB de almacenamiento SSD local
- Ubuntu 24.04 LTS u otra versión actual de Ubuntu compatible con Docker
- Docker Engine y Docker Compose instalados en el VPS
- Un dominio o subdominio apuntando al VPS mediante un registro A (algo como status.example.com)
- Acceso SSH y soltura básica con la línea de comandos
Si aún no tienes Docker instalado, sigue la guía de instalación de Docker para Ubuntu. Instala Docker Engine y el complemento Compose que usamos más abajo.
Por qué el VPS de monitorización debe estar separado de lo que vigila
La producción y la monitorización en el mismo servidor comparten el mismo dominio de fallo. Si ese servidor se detiene, desaparecen a la vez la aplicación y el sistema encargado de enviar la alerta.
Dos configuraciones prácticas mejoran esto:
- Mismo proveedor, ubicación distinta. Coloca la producción y la monitorización en hosts separados y en ubicaciones distintas. Esto reduce la exposición a un fallo de un solo servidor o de un solo centro de datos, pero no protege frente a todos los incidentes de red o de plano de control que afecten a todo el proveedor.
- Un proveedor completamente distinto. Alojar el monitor en otro sitio añade protección frente a incidentes que afecten a todo el proveedor. A cambio, tendrás otra cuenta, otra factura y otra superficie operativa que gestionar.
Una única instancia de Uptime Kuma sigue sin tener vigilancia externa. Añade una comprobación HTTP(S) externa sobre su página de estado pública. El plan gratuito de UptimeRobot incluye actualmente 50 monitores con intervalos de cinco minutos. Esto no hará que Uptime Kuma sea de alta disponibilidad, pero te avisará cuando el propio monitor desaparezca.
La misma regla se aplica a las páginas de estado públicas: lo que te avisa del fallo no debe compartir dominio de fallo con lo que falla.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxDimensionar el VPS
Uptime Kuma no tiene una fórmula fiable que relacione el número de monitores con la RAM, porque la carga cambia según el tipo de monitor, el intervalo, la configuración de reintentos y la retención del histórico. Las comprobaciones simples de HTTP(S), TCP, ping y DNS son más ligeras que las de Browser Engine, que ejecutan Chromium.
Para un conjunto pequeño de comprobaciones básicas, empieza con 1 vCPU, 1 GB de RAM y almacenamiento SSD local. Vigila el uso real con docker stats uptime-kuma y el crecimiento de la base de datos con du -sh /opt/uptime-kuma/data. Añade memoria cuando el uso se mantenga alto, cuando el contenedor informe de un OOM kill o cuando introduzcas comprobaciones de Browser Engine.
La imagen v2 completa incluye Chromium y MariaDB integrado; la documentación de las etiquetas de Docker explica la diferencia entre las imágenes full y slim.
Desplegar Uptime Kuma con Docker Compose
Guarda este archivo como docker-compose.yml en /opt/uptime-kuma/:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
# Bind to localhost only. The reverse proxy will expose it on 443.
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
Tres líneas merecen atención:
- image: louislam/uptime-kuma:2 fija la versión mayor. La etiqueta :2 sigue la línea estable 2.x. No uses :latest.
- 127.0.0.1:3001:3001 enlaza el contenedor solo a localhost. Internet nunca debe llegar directamente al puerto 3001. El proxy inverso es quien tiene el certificado TLS y el nombre de host público.
- El volumen de datos contiene la base de datos, la configuración de los monitores y el histórico. Mantenlo en almacenamiento local, porque la documentación de instalación de Uptime Kuma advierte de que los sistemas de archivos sin bloqueo POSIX fiable, incluidas muchas configuraciones NFS, pueden corromper SQLite. Detén la stack antes de hacer una copia a nivel de sistema de archivos.
Levántalo y comprueba:
sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps
Salida esperada de docker compose ps:
NAME IMAGE STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 Up (healthy) 127.0.0.1:3001->3001/tcp
Para entrar al panel por primera vez, no abras el puerto 3001 a Internet, ni siquiera un momento. Accede por un túnel SSH:
ssh -L 3001:127.0.0.1:3001 [email protected]
Abre http://localhost:3001 en el navegador, crea la cuenta de administrador, pon una contraseña fuerte y cierra el túnel. A partir de ahora el panel te llega por HTTPS a través del proxy inverso.
Si no necesitas hacerlo manualmente con Compose, también ofrecemos Uptime Kuma como aplicación de un clic. La ficha actual indica la v1, así que no coincide con la instalación v2 de esta guía. Usa la vía manual con Compose si necesitas específicamente la v2.
Proxy inverso y TLS
No expongas Uptime Kuma directamente. Pon un proxy inverso delante para el TLS, un manejo correcto de las URL y un único punto de entrada público. Dos caminos.
Caddy. Si aún no tienes Caddy instalado, sigue sus pasos oficiales de paquete para Ubuntu. Con Caddy corriendo como servicio del host, el Caddyfile de abajo hace de proxy hacia Uptime Kuma en loopback y gestiona la emisión y renovación del certificado automáticamente.
Consejo: cuando el VPS de monitorización solo aloja Uptime Kuma, usa Caddy. El Caddyfile son tres líneas, y Caddy se encarga solo de emitir y renovar el certificado. Sin Certbot y sin un temporizador de renovación aparte al que atender a las 4 de la mañana.
Guarda esto como /etc/caddy/Caddyfile:
status.example.com {
reverse_proxy 127.0.0.1:3001
}
Recarga Caddy:
sudo systemctl reload caddy
Comprueba:
curl -I https://status.example.com
Deberías recibir una respuesta 2xx o 3xx correcta con un certificado válido. Si la conexión falla, comprueba que el registro A o AAAA del dominio apunta a este VPS, que los puertos 80 y 443 son accesibles y que Caddy puede enlazarse a ambos. Todo esto forma parte de los requisitos del HTTPS automático de Caddy.
Nginx Proxy Manager. Si NPM corre directamente en el host, añade un Proxy Host para status.example.com, reenvíalo a 127.0.0.1 en el puerto 3001, pide un certificado Let's Encrypt y activa Websockets Support. Si NPM corre en Docker, 127.0.0.1 apunta de vuelta al propio contenedor de NPM. Conecta en su lugar NPM y Uptime Kuma a la misma red de Docker y luego apunta el proxy host a uptime-kuma en el puerto 3001.
Enrutado de notificaciones: Telegram, Discord, Slack
Uptime Kuma puede enviar un mismo evento de monitor a varios canales de notificación. Configura cada proveedor una vez y luego asocia uno o varios canales a un monitor según quién necesite la alerta.
Las notificaciones se configuran de forma global en Ajustes > Notificaciones, y luego se asignan a cada monitor. Cada monitor puede disparar uno o varios canales. La misma alerta puede llegar a Telegram para el ingeniero de guardia, a Slack para el equipo y al correo para el registro de auditoría, todo desde un único evento.
Telegram
- En Telegram, escribe a @BotFather y ejecuta /newbot. Elige un nombre y un nombre de usuario. BotFather responde con un token de bot. Guárdalo.
- Envía cualquier mensaje a tu nuevo bot. Después abre https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates en un navegador. Busca el campo chat.id: ese es tu ID de chat.
- En Uptime Kuma: Ajustes > Notificaciones > Configurar notificación > Telegram. Pega el token del bot y el ID de chat. Haz clic en Probar. Comprueba que el bot envía la alerta de prueba.
- Si el mensaje de prueba no llega, comprueba que el token del bot y el ID de chat son correctos, y que el cortafuegos del VPS permite salidas HTTPS hacia api.telegram.org.
Discord
- Abre el servidor de Discord donde quieres las alertas. Haz clic derecho en el canal de destino y luego Editar canal > Integraciones > Webhooks > Nuevo webhook. Ponle un nombre (algo como «Uptime Kuma»), elige el canal y copia la URL del webhook.
- En Uptime Kuma: Ajustes > Notificaciones > Configurar notificación > Discord. Pega la URL del webhook. Si quieres, define también el nombre de usuario y el avatar.
- Haz clic en Probar. Comprueba que el webhook publica la alerta de prueba en el canal.
Slack
- En Slack, crea un Incoming Webhook para el canal donde quieres las alertas. Slack devuelve una URL de webhook con la forma https://hooks.slack.com/services/T.../B.../....
- En Uptime Kuma: Ajustes > Notificaciones > Configurar notificación > Slack. Pega la URL del webhook. Si quieres, configura también el icono y el canal alternativo.
- Haz clic en Probar.
Cuando todas las pruebas pasen, edita cada monitor y selecciona los canales de notificación que debe usar. Ajusta Max Retries (reintentos máximos) y Retry Interval (intervalo entre reintentos) de modo que un fallo breve no dispare una alerta de inmediato.
La página de estado integrada (y cuándo se te quedará corta)
Uptime Kuma incluye páginas de estado públicas con slugs personalizados, monitores agrupados, dominios propios, publicaciones de incidentes y avisos de mantenimiento programado. También puedes publicar varias páginas de estado desde una misma instancia, para distintos servicios o públicos.
Su mayor limitación es la comunicación con los clientes. Ahora mismo los visitantes no pueden suscribirse por correo a las actualizaciones directamente desde una página de estado, y esa página pública sigue formando parte de la misma aplicación Uptime Kuma que el panel del operador. La autosuscripción de visitantes sigue registrada como una solicitud de función abierta.
Si necesitas suscripciones de clientes o un sistema de estado separado del panel de monitorización, Kener es una alternativa. Nuestro artículo sobre la stack de monitorización autoalojada explica cómo se pueden combinar las dos herramientas.
Problemas habituales
Las notificaciones fallan en silencio cuando el cortafuegos del VPS bloquea el HTTPS saliente. Síntoma: el botón Test funciona en algunos canales y en otros no. Solución: comprueba que se permiten las conexiones HTTPS salientes y que curl -I https://api.telegram.org funciona desde el VPS.
El navegador muestra «ERR_TOO_MANY_REDIRECTS» tras activar el proxy. Busca redirecciones duplicadas de HTTP a HTTPS en Caddy, Nginx Proxy Manager o cualquier CDN por delante. Uptime Kuma debe seguir sirviendo HTTP en el puerto 3001 mientras el proxy inverso público termina el TLS. Si activas las cabeceras de proxy de confianza, la ruta actual es Ajustes > Proxy inverso > Cabeceras HTTP > Trust Proxy.
El contenedor se reinicia cada pocos minutos. Comprueba si el contenedor se detuvo por quedarse sin memoria y luego vigila su consumo actual con docker stats uptime-kuma. Si el contenedor fue eliminado por OOM o la memoria se mantiene cerca del límite del VPS, añade RAM, reduce las comprobaciones pesadas o amplía sus intervalos.
La página de estado funciona en localhost pero no a través del nombre de host público. Comprueba que el proxy inverso reenvía la ruta raíz sin cambios, conserva la cabecera Host y admite WebSockets. Uptime Kuma no soporta instalarse en un subdirectorio, así que usa un dominio o subdominio dedicado en lugar de una ruta como example.com/uptime-kuma.
Para terminar
Uptime Kuma en un VPS aparte te da control sobre las comprobaciones, el enrutado de alertas y la página de estado pública, pero también te deja a cargo de las actualizaciones, las copias de seguridad, los parches del sistema y la vigilancia externa del propio monitor. Elige un VPS en una ubicación distinta de la de producción, despliega la v2 con Docker Compose o usa la app de un clic tras comprobar la versión que anuncia, pon Caddy delante y conecta los canales que tu equipo mira.
Preguntas frecuentes
¿Cuánta RAM necesita Uptime Kuma?
Uptime Kuma no tiene una fórmula fiable que relacione el número de monitores con la RAM, porque el consumo varía según el tipo de monitor, el intervalo de comprobación, la configuración de reintentos, la retención del histórico y el uso del Browser Engine. Para un conjunto pequeño de comprobaciones básicas, empieza con 1 GB de RAM y vigila el consumo real con docker stats uptime-kuma. Añade memoria si el consumo se mantiene cerca del límite o si el contenedor muere por OOM.
¿Debo ejecutar Uptime Kuma en el mismo servidor que mi aplicación?
No. Si la herramienta de monitorización y la aplicación comparten servidor, un fallo las deja fuera de línea a la vez y pierdes las alertas justo cuando más las necesitas. Ejecuta Uptime Kuma en un VPS aparte, idealmente en otro centro de datos.
¿Puede Uptime Kuma enviar alertas a Telegram, Discord y Slack?
Sí. Telegram, Discord y Slack son servicios de notificación integrados, junto al correo, los webhooks genéricos, PagerDuty, ntfy, Mattermost y muchos más. Telegram usa un token de bot y un ID de chat, mientras que Discord y Slack usan URL de webhook. Puedes asociar varios canales de notificación al mismo monitor.
¿Cuál es la diferencia entre Uptime Kuma y UptimeRobot?
Uptime Kuma es autoalojado, así que tú gestionas el servidor, las actualizaciones, las copias de seguridad y el enrutado de alertas. Admite intervalos de comprobación de hasta 20 segundos. UptimeRobot es SaaS alojado, y su plan gratuito actual incluye 50 monitores con comprobaciones cada cinco minutos. Elige Uptime Kuma si quieres control, o UptimeRobot si no quieres operar el servidor de monitorización.
¿Tiene Uptime Kuma una página de estado pública?
Sí. Puedes elegir qué monitores son visibles, agruparlos, publicar varias páginas de estado, asignarles dominios propios y programar mensajes de mantenimiento. La autosuscripción por correo de los visitantes no viene incluida, así que usa una herramienta de página de estado orientada a clientes cuando estos necesiten suscribirse a las novedades.
