Uptime Kuma encaja en estos escenarios:

• Tienes algunos sitios web, APIs o servicios de backend que vigilar.
• Quieres recibir notificaciones por Telegram, correo o WeCom inmediatamente después de una caída.
• Necesitas una página de estado sencilla para decir a los usuarios qué servicios están normales y cuáles caídos.
• No quieres montar el stack relativamente pesado de Prometheus + Grafana.
• Solo tienes un VPS de bajas prestaciones y aun así quieres que funcione.

No es muy adecuado para estos escenarios:

• Necesitas análisis complejos de métricas, como tendencias de CPU, memoria, disco o consultas lentas.
• Necesitas almacenar datos de series temporales durante años.
• Necesitas permisos multiinquilino, informes complejos y auditoría empresarial.

Mi consejo es: usa Uptime Kuma para monitorear "si el servicio está vivo" y usa Prometheus/Grafana para monitorear "por qué se ha vuelto lento". No son el mismo tipo de cosa.

Uptime Kuma es muy ligero y para uso personal no es exigente con la máquina.

Lo que realmente hay que tener en cuenta es esto: es mejor no poner el panel de monitoreo en la misma máquina que todos los servicios de negocio.

Por ejemplo, si solo tienes un VPS y tanto el sitio web como Uptime Kuma se ejecutan en esa máquina, cuando la máquina se caiga, Uptime Kuma también se caerá, y por supuesto no podrá notificártelo. Así que una mejor práctica es:

• El negocio principal en la máquina A.
• Uptime Kuma en la máquina B.
• Si el presupuesto es limitado, un VPS anual barato para la máquina B es suficiente.

Si por ahora solo tienes una máquina, tampoco es imposible desplegarlo. Al menos puedes empezar monitoreando el dominio, el certificado, los puertos y el estado de los contenedores Docker. Más adelante, cuando el negocio sea más importante, migra el panel de monitoreo a otro VPS.

Entorno predeterminado de este artículo:

• Ubuntu 22.04 / 24.04 o Debian 12.
• Docker y Docker Compose ya instalados.
• Tienes un dominio, por ejemplo status.example.com.
• Los puertos 80/443 son accesibles.
• Caddy ya está instalado, o estás dispuesto a configurarlo según este artículo.

Primero confirma que Docker está disponible:

docker version
docker compose version

Confirma que el dominio ya resuelve al VPS:

dig status.example.com +short

Si aún no has instalado Caddy, puedes leer primero este artículo: Guía completa de proxy inverso con Caddy en un VPS.

Suelo poner este tipo de servicios en /opt:

sudo mkdir -p /opt/uptime-kuma
sudo chown -R "$USER":"$USER" /opt/uptime-kuma
cd /opt/uptime-kuma

Crea el directorio de datos:

mkdir -p data

Los monitores, la configuración de notificaciones, las páginas de estado y la información de usuarios de Uptime Kuma están todos en /app/data. Este directorio debe persistirse, de lo contrario los datos se perderán más adelante cuando elimines contenedores o actualices imágenes.

Crea docker-compose.yml:

nano docker-compose.yml

Escribe:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

Aquí he vinculado deliberadamente solo 127.0.0.1:3001, para no exponer el puerto 3001 directamente a Internet.

La razón es simple: solo se abren 80/443 a Internet y Uptime Kuma está detrás de Caddy. Así los certificados, HTTPS y el control de acceso son más fáciles de gestionar.

Si también quieres usar Uptime Kuma para monitorear contenedores Docker en el mismo VPS, necesitas montar además el socket de Docker:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "127.0.0.1:3001:3001"

Fíjate en esta línea:

- /var/run/docker.sock:/var/run/docker.sock:ro

Sin ella, Uptime Kuma normalmente no puede ver los contenedores Docker del host, así que no podrás añadir monitores de tipo Docker Container.

Pero tampoco montes el socket de Docker en todos los contenedores sin pensarlo. Puede leer el estado de Docker y en sí mismo es un punto de entrada muy sensible. Solo se recomienda activarlo cuando realmente necesites monitorear contenedores Docker, y seguir manteniendo Uptime Kuma accesible solo por HTTPS, sin exponer el puerto 3001 directamente a Internet.

Inicia el servicio:

docker compose up -d

Comprueba el estado:

docker compose ps
docker compose logs -f --tail=100

Prueba local:

curl -I http://127.0.0.1:3001

Si hay respuesta, el contenedor ya está en ejecución.

Edita el Caddyfile:

sudo nano /etc/caddy/Caddyfile

Añade:

status.example.com {
    encode zstd gzip

    header {
        X-Content-Type-Options nosniff
        Referrer-Policy strict-origin-when-cross-origin
    }

    reverse_proxy 127.0.0.1:3001
}

Comprueba la configuración y recarga:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Abre en el navegador:

https://status.example.com

La primera visita te pedirá crear una cuenta de administrador. No uses una contraseña débil; el panel de monitoreo normalmente guarda tokens de canales de notificación, direcciones Webhook e información de servicios, y si lo escanean resulta bastante problemático.

Después de iniciar sesión, haz clic en Add New Monitor y empieza con el monitoreo de sitios web.

Configuración habitual:

• Monitor Type: HTTP(s)
• Friendly Name: Sitio principal
• URL: https://example.com
• Heartbeat Interval: 60 segundos o 120 segundos
• Retries: 2-3 veces
• Accepted Status Codes: 200-299

Normalmente no pongo el intervalo demasiado corto. Muchos VPS pequeños, rutas baratas y redes internacionales tienen pequeñas fluctuaciones ocasionales, y es normal. Si lo configuras para comprobar cada 20 segundos, al final puede que te asustes a ti mismo.

Una configuración más estable es:

间隔：60 秒
重试：3 次
失败后再通知

Así se filtran algunas fluctuaciones breves de red.

No añadas 100 monitores de golpe; primero vigila lo que de verdad es importante.

Se recomienda empezar por estas categorías:

Lo que más uso es HTTP(s) + Keyword. Porque algunos sitios web pueden devolver 200 incluso cuando están dando errores. Por ejemplo, el framework de la aplicación muestra una página de error, el código de estado HTTP es normal, pero el contenido de la página ya no es lo que quieres.

En ese caso puedes configurar un Keyword:

必须包含：网站标题、品牌名、某个固定文字

Si la página ya no contiene esta palabra, Uptime Kuma lo determinará como anómalo.

Si quieres añadir monitoreo de Docker Container, primero confirma que el Compose anterior ha montado /var/run/docker.sock. De lo contrario, cuando selecciones el tipo Docker en Uptime Kuma, lo más probable es que no pueda conectarse al daemon de Docker.

Telegram es uno de los métodos de notificación que más recomiendo: rápido, gratuito y sencillo de configurar.

El proceso general:

1. Busca @BotFather para crear un Bot.
2. Obtén el Bot Token.
3. Envía un mensaje al Bot.
4. Obtén el Chat ID.
5. Añade una notificación de Telegram en Uptime Kuma.

Si no sabes cómo obtener el Chat ID, puedes visitar:

https://api.telegram.org/bot你的TOKEN/getUpdates

Encuentra chat.id dentro.

En Uptime Kuma, entra en:

Settings -> Notifications -> Setup Notification

Selecciona Telegram, rellena el Bot Token y el Chat ID, y luego haz clic en Test.

Después de que la prueba sea exitosa, recuerda establecer este canal de notificación como predeterminado, o vincularlo manualmente a los monitores importantes.

Las notificaciones por correo son buenas como respaldo. A veces el sistema del teléfono silencia Telegram, pero el correo al menos deja un registro.

Configuración SMTP habitual:

Host: smtp.example.com
Port: 587
Security: STARTTLS
Username: [email protected]
Password: 邮箱授权码
From: [email protected]

Ojo con varias trampas:

• Muchos proveedores de correo no permiten usar la contraseña de inicio de sesión; usa una contraseña específica de aplicación.
• El proveedor del VPS puede restringir el puerto 25; prioriza 587 o 465.
• Es mejor configurar SPF, DKIM y DMARC para el buzón remitente, de lo contrario es fácil que acabe en spam.
• No introduzcas la contraseña de tu buzón personal principal.

Si es solo para uso personal, Telegram + correo ya es suficiente. En escenarios empresariales puedes conectar además Slack, Discord, Webhook, WeCom, etc.

La página de estado de Uptime Kuma es muy práctica. Por ejemplo, si tienes varios servicios:

• Sitio oficial
• API
• Sitio de documentación
• Sitio de descargas
• Panel de administración

Puedes crear una página pública:

https://status.example.com/status/main

Después de que los usuarios o clientes la abran, pueden ver qué servicios están normales y cuáles caídos.

Sin embargo, no recomiendo hacer públicos todos los servicios internos. La página de estado solo debe incluir lo que los usuarios necesitan saber, como el sitio oficial, la API y el servicio de descargas. No expongas bases de datos, Redis ni paneles de administración internos; no hay necesidad de mostrar a otros tu estructura interna.

Mucha gente olvida este punto.

Si Uptime Kuma solo monitorea a otros, nadie sabrá cuándo se cae él mismo. Una forma más fiable es:

• Usar otro servicio de monitoreo gratuito para monitorear status.example.com.
• O buscar otro VPS de bajo costo para ejecutar un segundo Kuma y que se monitoreen mutuamente.
• O usar un servicio de terceros como respaldo, como Better Stack, Healthchecks, UptimeRobot, etc.

Los proyectos personales no necesitan ser demasiado complicados, pero al menos debes saber un hecho: el monitoreo de un solo punto solo puede descubrir los problemas de otros, no el problema de tu propia caída total.

Los datos de Uptime Kuma están en /opt/uptime-kuma/data. Basta con hacer copia de seguridad de este directorio.

La copia de seguridad más sencilla:

cd /opt/uptime-kuma
mkdir -p /opt/backups/uptime-kuma

tar czf /opt/backups/uptime-kuma/uptime-kuma-$(date +%F-%H%M).tar.gz data

Si ya usas restic, rclone o almacenamiento de objetos para copias de seguridad, solo tienes que añadir este directorio a la lista de copias.

Se recomienda hacer copia de seguridad al menos de:

• data/kuma.db
• data/upload/
• Todo el /opt/uptime-kuma/data

Al restaurar, detén primero el servicio:

cd /opt/uptime-kuma
docker compose down
mv data data.broken.$(date +%F-%H%M)
tar xzf /opt/backups/uptime-kuma/uptime-kuma-你的日期.tar.gz

docker compose up -d

Después de restaurar, comprueba: si los monitores siguen ahí, si los canales de notificación se pueden probar y si el enlace de la página de estado es normal.

Haz copia de seguridad antes de actualizar:

cd /opt/uptime-kuma
tar czf /opt/backups/uptime-kuma/before-upgrade-$(date +%F-%H%M).tar.gz data docker-compose.yml

Descarga la nueva imagen y reinicia:

docker compose pull
docker compose up -d

Revisa los registros:

docker compose logs -f --tail=100

Si no quieres seguir siempre la última versión, puedes fijar la versión de la imagen. Para proyectos personales, louislam/uptime-kuma:2 es más cómodo; en entornos de producción es más recomendable actualizar primero en una máquina de pruebas.

Antes del uso formal se recomienda confirmar:

• El directorio data está persistido.
• El puerto 3001 está vinculado solo a 127.0.0.1.
• El dominio usa HTTPS.
• La contraseña del administrador es suficientemente fuerte.
• Se ha configurado al menos un canal de notificación instantánea.
• Los monitores importantes están vinculados a notificaciones.
• Si quieres monitorear contenedores Docker, /var/run/docker.sock está montado.
• La página de estado no expone servicios internos.
• El directorio de datos está incluido en las copias de seguridad.
• Se ha hecho una prueba de notificación.
• Se ha hecho un simulacro de restauración.

Uptime Kuma es más adecuado para el "monitoreo de primera capa": el sitio web no abre, la API se cae, el puerto no responde, el certificado está a punto de caducar, la palabra clave ha desaparecido; puede avisarte rápidamente.

Pero no es omnipotente. Te dice "el servicio tiene un problema", pero no necesariamente "por qué hay un problema". Si también quieres ver métricas de CPU, memoria, disco y contenedores, puedes añadir Prometheus + Grafana; si es solo un proyecto personal, el sitio web de un equipo pequeño o unas pocas aplicaciones autoalojadas, Uptime Kuma ya es suficiente.

Mi propia costumbre es: añadir primero los servicios importantes a Uptime Kuma, al menos asegurar que alguien avise cuando haya una caída; cuando el servicio se vuelva más complejo, añadir después registros, métricas y trazabilidad. No hagas que el sistema de monitoreo sea más complejo que el negocio desde el principio.