Por qué auto-alojar Uptime Kuma en un VPS
Los servicios de monitorización SaaS suelen facturar por número de monitores o por frecuencia de comprobación, y limitan el intervalo a 1 o 5 minutos en los planes gratuitos. Al desplegar Uptime Kuma en su propio VPS, supervisa tantos sitios como quiera, además de API, puertos TCP, contenedores Docker o servidores DNS, con intervalos de hasta 20 segundos. Alojar la sonda en un VPS distinto de sus servidores de producción es una ventaja: si su servidor de aplicaciones cae, el VPS de monitorización sigue en pie y dispara la alerta. Uptime Kuma ofrece además una página de estado pública que puede mostrar a sus clientes, y más de 90 canales de notificación (Telegram, correo electrónico, Discord, webhook). Todo permanece en su infraestructura, sin enviar sus URL internas a un tercero.
Las ventajas concretas de esta plantilla
- Monitores sin límite: HTTP(s), TCP, ping, DNS, contenedores Docker, certificados SSL y palabras clave de página.
- Alertas multicanal (Telegram, correo electrónico, Discord, Slack, webhook) con más de 90 integraciones.
- Página de estado pública personalizable para compartir con sus clientes o su equipo.
- Vigilancia de la caducidad de los certificados SSL para no volver a llevarse una sorpresa.
- Historial y estadísticas de uptime conservados en local, sin retención de pago.
- Comprobaciones cada 20 segundos, algo imposible en la mayoría de los planes gratuitos.
Requisitos previos para alojarlo
Uptime Kuma es muy frugal: un VPS de 1 vCPU con 512 MB a 1 GB de RAM basta de sobra para vigilar varias decenas de monitores. La base de datos SQLite integrada ocupa poco espacio; calcule de 2 a 5 GB de disco según el historial conservado. Necesita Docker instalado, un nombre de dominio o subdominio (status.mondomaine.com) apuntando al VPS, y los puertos 80/443 abiertos para el reverse proxy y el SSL. Para una supervisión fiable, aloje Uptime Kuma preferentemente en un VPS distinto de sus servidores de producción.
Desplegar Uptime Kuma con Docker y SSL
Crear el volumen y lanzar el contenedor
En el VPS, cree un volumen persistente y arranque después el contenedor:
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1. La interfaz queda accesible en el puerto 3001.Configurar la cuenta de administrador
Abra
http://IP_DU_VPS:3001y cree la cuenta de administrador en la primera conexión. Elija una contraseña robusta: esta interfaz tendrá acceso a todas las URL que supervise.Poner un reverse proxy y el SSL por delante
Configure Nginx o Caddy para exponer
status.mondomaine.comhacialocalhost:3001. Con Caddy bastan dos líneas para obtener un certificado Let's Encrypt automático:status.mondomaine.com { reverse_proxy localhost:3001 }.Añadir sus primeros monitores
Cree monitores HTTP(s) para sus sitios, un monitor TCP para su base de datos, una comprobación SSL para vigilar la caducidad de los certificados y una palabra clave para detectar las páginas de error servidas con HTTP 200.
Conectar las notificaciones y la página de estado
En Ajustes > Notificaciones, añada Telegram o correo electrónico y pruebe el envío. Active después una página de estado pública que agrupe sus servicios de cliente, con un nombre de dominio dedicado si lo necesita.
Conectarse por primera vez
Abra la URL sin demora: la primerísima pantalla le pide crear la cuenta de administrador (nombre de usuario + contraseña) y, a continuación, accede al panel de control. No existe ninguna credencial por defecto.
Para evitar las falsas alertas ante una microincidencia de red, configure el campo Retries (por ejemplo, 3 fallos consecutivos antes de alertar) y un Heartbeat Interval adecuado. Combínelo con una notificación de grupo: Uptime Kuma puede enviar un mensaje agregado en lugar de una alerta por monitor, lo que evita saturar su canal de Telegram durante una caída de red general que tumba diez servicios de golpe.
Lo que el monitor de Docker no ve
El monitor de tipo Docker Container consulta el motor de Docker y lee el estado del contenedor. Es práctico, pero ese estado describe el proceso, no el servicio. Una issue abierta en el repositorio de la herramienta (#7956, notificada en la versión 1.23.17) da un caso claro: un contenedor lanzado con una política de reinicio (restart: always, unless-stopped, o la opción --restart=always del comando de despliegue anterior) que falla en bucle aparece como UP con el mensaje «restarting». El autor del informe vincula este comportamiento con la comprobación de State.Running, que sigue siendo verdadera durante el intervalo entre dos reinicios. El monitor permanece en verde, no sale ninguna notificación y su aplicación ya no responde. Al releer el hilo, la issue seguía abierta, sin corrección fusionada: solo figuran parches propuestos. El monitor de Docker responde a la pregunta «¿está en marcha el contenedor?», no a «¿sirve correctamente la aplicación a sus usuarios?».
Por qué una sola señal no basta
- El proceso funciona, el servicio no — un contenedor puede arrancar, fallar dos segundos después y reiniciarse: en cada sondeo, el motor de Docker puede describirlo como en ejecución.
- Sin healthcheck, sin veredicto — sin una instrucción
HEALTHCHECKen la imagen ni un bloquehealthchecken su archivo compose, el motor solo tiene el estado bruto que transmitir a Uptime Kuma. - Unhealthy no alerta en todas partes — según el hilo de la issue, tratar el estado «unhealthy» como DOWN se fusionó para la rama 2.1.0 (PR #6292), mientras que la rama 1.x deja ese caso en espera (PENDING), es decir, sin alerta. El despliegue anterior usa la imagen
louislam/uptime-kuma:1. - La política de reinicio oculta la avería —
restart: alwaysayuda a recuperarse de un incidente aislado, pero convierte una avería franca en intermitente, que los sondeos muy espaciados no detectan. - Una herramienta de supervisión puede tener sus propios puntos ciegos — una función que va bien un mes puede retroceder en la siguiente actualización: verifique sus alertas con una prueba real, no solo leyendo la interfaz.
Completar el monitor de Docker con varias señales
Vigilar la propia aplicación
Añada un monitor HTTP(s), o «HTTP(s) - Keyword» si la página debe contener una palabra concreta, sobre la URL de la aplicación (pública o interna del VPS). Un contenedor en bucle de fallos no responde: este monitor falla mientras el monitor de Docker sigue en verde. Mantenga Retries en 3 para evitar falsas alertas.
Declarar un healthcheck en el compose
En el servicio vigilado, añada por ejemplo
healthcheck: test: ["CMD-SHELL", "wget -q --spider http://localhost:3000/ || exit 1"]coninterval: 10s,timeout: 3s,retries: 3ystart_period: 30s. Adapte el puerto y la herramienta: la imagen debe contenerwgetocurl. Docker muestra entonces el estado healthy o unhealthy, que usted lee endocker ps.Leer el contador de reinicios
En el VPS,
docker ps --filter status=restartinglista los contenedores que se están reiniciando, ydocker inspect mon-app | grep -E "RestartCount|Status"da el número de reinicios y el estado. UnRestartCountque sube de un control al siguiente señala un bucle, aunque el estado mostrado sea running.Enviar un latido con un monitor Push
Cree un monitor de tipo Push en Uptime Kuma y lance por cron en el VPS un pequeño script que lea el
RestartCounty llame a la URL Push solo si no ha cambiado desde el control anterior. Si el contador sube, falta el latido y el monitor pasa a DOWN: la alerta se apoya en un dato que el monitor de Docker no mira.Probar la cadena de alertas de verdad
Lance un contenedor que falle a propósito:
docker run -d --name crash-test --restart unless-stopped alpine sh -c "sleep 2; exit 1". Cree un monitor de Docker sobrecrash-test: si se mantiene UP mientrasdocker ps --filter status=restartinglo lista, está reproduciendo el caso descrito en la issue. Compruebe que su monitor HTTP o Push sí dispara la notificación y, después, elimine el contenedor condocker rm -f crash-test.
El Retry de un monitor TCP: un caso corregido, a comprobar en su versión
Una segunda issue (#7979) afectaba al campo Retries. En la versión 2.5.6, un monitor de tipo TCP Port configurado con SSL o StartTLS ignoraba este ajuste: ante el primer fallo pasaba directamente a rojo, mientras que los monitores HTTP(s) con el mismo número de intentos pasaban antes a espera. El caso es más estrecho de lo que sugiere el título: afecta a la variante TCP con TLS, no a todos los monitores TCP. La issue se cerró con la corrección de la PR #7989, que las notas de la versión 2.5.7 enumeran. Si vigila un puerto TLS (correo, XMPP, base de datos cifrada) con una versión anterior, recibe alertas por cada fallo aislado. Actualice la herramienta y compruebe después el comportamiento parando el servicio probado: el monitor debe pasar a espera antes de caer. Otra precisión del hilo: el campo Down Count es un contador ligado al reenvío de notificaciones, no un contador de intentos.
Una alerta, varias señales
Asocie el monitor HTTP, el monitor Push y el monitor de Docker a la misma notificación de grupo, y reserve el mensaje de urgencia para la señal de la aplicación: una página que ya no responde es una avería, un RestartCount que sube es un aviso que tratar en la hora siguiente. Así, el fallo de un solo monitor ya no deja en silencio su canal de Telegram.
La documentación oficial
Para la configuración avanzada y las opciones propias de la herramienta, consulte la documentación oficial de Uptime Kuma. Esta guía cubre la puesta en línea en un VPS; la documentación del editor sigue siendo la referencia para los ajustes finos, las actualizaciones mayores y los casos de uso específicos.
