Uptime Kuma: Monitoreo Self-Hosted Gratis para tu Homelab (Guía Completa 2025)

¿Cuántas veces te has despertado con mensajes de “¿Por qué no funciona X servicio?” sin tener ni idea de cuándo se cayó? Si gestionas un homelab, servicios web o simplemente quieres saber cuándo tu infraestructura tiene problemas antes de que te lo digan tus usuarios, necesitas monitoring. El problema es que servicios como Pingdom cuestan $85/mes para 200 monitores, y UptimeRobot limita el intervalo a 5 minutos en su plan gratuito.

Uptime Kuma es la solución open-source que necesitas: self-hosted, gratis, con interfaz moderna, 90+ servicios de notificaciones, status pages públicas y chequeos cada 20 segundos. En esta guía completa aprenderás a instalarlo con Docker, configurar monitores para todo tu homelab y recibir alertas instantáneas en Discord o Telegram.

¿Qué es Uptime Kuma?

Uptime Kuma es una herramienta de monitoreo self-hosted creada por Louis Lam (@louislam) con más de 6,000 commits y 805 contributors. Se define como “a fancy self-hosted monitoring tool” y no miente: su interfaz construida con Vue 3 y Bootstrap 5 es mucho más moderna que la mayoría de alternativas comerciales.

Características principales:

• Monitoreo cada 20 segundos (vs 5 minutos de UptimeRobot free)
• Monitores ilimitados (tu único límite es el hardware)
• 90+ servicios de notificaciones (Discord, Telegram, Slack, email, webhooks, etc.)
• Status pages públicas personalizables (sin pagar extra)
• Soporte Docker nativo (monitorea tus containers directamente)
• Control total de tus datos (self-hosted)
• 2FA integrado para seguridad
• Certificados SSL monitoring con alertas de expiración
• WebSocket UI (actualización en tiempo real sin refresh)

A diferencia de servicios SaaS, Uptime Kuma te da control absoluto: tus datos nunca salen de tu servidor, puedes modificar el código fuente si necesitas features custom, y el único costo es el hosting (~$3-5/mes en un VPS básico).

Uptime Kuma vs UptimeRobot vs Pingdom: Comparativa Real

Antes de invertir tiempo en configurar tu monitoring, debes saber qué alternativa se adapta mejor a tus necesidades. Aquí está la comparativa real con datos de 2025:

Comparativa de costos para 200 monitores:

• Uptime Kuma: $0 software + ~$5/mes VPS (Hetzner CPX11) = $5/mes total
• UptimeRobot: $28/mes (150 monitores extra sobre los 50 free)
• Pingdom: $85/mes (plan Advanced para 200 monitores)

Uptime Kuma es 5.6x más barato que UptimeRobot y 17x más barato que Pingdom para el mismo número de monitores.

¿Cuándo elegir cada opción?

Elige Uptime Kuma si:

• Gestionas homelab con muchos servicios
• Quieres control total de tus datos
• Necesitas monitorear Docker containers
• Te interesa customizar código (open source)
• Quieres chequeos frecuentes (<60 segundos)
• Tienes conocimientos básicos Docker/Linux

Elige UptimeRobot si:

• Solo monitorizas pocos servicios externos (<50)
• No quieres mantener infraestructura
• Necesitas multi-location monitoring desde ya
• Prefieres SaaS sin preocupaciones

Elige Pingdom si:

• Empresa con presupuesto
• Necesitas transaction monitoring (flujos complejos)
• Requieres analytics profundos y reportes
• SLA garantizado crítico

Para la mayoría de homelabbers, desarrolladores indie y pequeños proyectos, Uptime Kuma es la opción obvia. Si estás montando tu homelab desde cero, el monitoring es uno de los primeros servicios que deberías configurar.

Requisitos Técnicos

Antes de empezar, asegúrate de tener:

Opción 1: Docker (Recomendado)

• Docker instalado (versión 20.10+)
• Docker Compose (v2.0+)
• 512 MB RAM mínimo (1 GB recomendado para 100+ monitores)
• 10 GB de almacenamiento (para base de datos SQLite)
• Sistema de archivos con POSIX file locks (ext4, xfs, btrfs – NO NFS/SMB)

Distribuciones soportadas: Ubuntu, Debian, Fedora, CentOS, Arch Linux, etc.

Opción 2: Non-Docker

• Node.js >= 20.4
• Git
• PM2 (para ejecutar en background)
• Linux o Windows 10+ (también macOS)

Sistemas NO soportados: FreeBSD, OpenBSD, NetBSD, Replit, Heroku.

VPS mínimo recomendado:

• 1 vCPU
• 512 MB RAM (Hetzner CPX11: €4.15/mes, DigitalOcean Basic: $4/mes)
• 10 GB SSD

Para 500+ monitores, sube a 2 vCPU y 2 GB RAM.

Instalación con Docker Compose: Paso a Paso

Vamos a instalar Uptime Kuma usando Docker Compose, el método más limpio y fácil de mantener.

1. Crear estructura de carpetas

# Crear directorio para Uptime Kuma
mkdir -p ~/homelab/uptime-kuma
cd ~/homelab/uptime-kuma

2. Crear docker-compose.yml

Crea el archivo docker-compose.yml con esta configuración básica:

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data
    environment:
      - UPTIME_KUMA_PORT=3001
      - UPTIME_KUMA_HOST=0.0.0.0

volumes:
  uptime-kuma-data:
    driver: local

Explicación de la configuración:

• image: louislam/uptime-kuma:2 – Usa la versión 2 (latest stable)
• restart: unless-stopped – Reinicia automáticamente tras crashes/reboots
• ports: "3001:3001" – Puerto por defecto (cambia el primero si quieres otro puerto externo)
• volumes: uptime-kuma-data:/app/data – Persiste configuración y base de datos
• UPTIME_KUMA_HOST=0.0.0.0 – Escucha en todas las interfaces (necesario para reverse proxy)

3. Levantar el servicio

# Iniciar en background
docker compose up -d

# Ver logs en tiempo real
docker compose logs -f uptime-kuma

Deberías ver algo como:

uptime-kuma  | 2025-11-03 10:00:00 [SERVER] Listening on http://0.0.0.0:3001
uptime-kuma  | 2025-11-03 10:00:00 [DB] Database ready

4. Acceder a la interfaz web

Abre tu navegador y ve a:

http://localhost:3001

O desde otra máquina en tu red local:

http://IP-DE-TU-SERVIDOR:3001

Primera vez: Te pedirá crear cuenta de administrador. Usa un username y contraseña seguros.

5. Configuración inicial recomendada

Una vez dentro:

• Activa 2FA: Settings → Security → Enable Two-Factor Auth
• Configura timezone: Settings → General → Timezone
• Cambia idioma (opcional): Settings → General → Language

¡Ya tienes Uptime Kuma funcionando! Ahora vamos a configurarlo con reverse proxy para acceso seguro con HTTPS.

Configuración con Reverse Proxy (Nginx/Traefik)

Para acceso seguro desde internet, necesitas un reverse proxy con HTTPS. Uptime Kuma usa WebSocket, así que la configuración es ligeramente diferente a un servicio HTTP normal.

Opción 1: Nginx Proxy Manager (La más fácil)

Si usas Portainer para gestionar Docker, simplemente:

• Proxy Hosts → Add Proxy Host
• Domain: uptime.tudominio.com
• Forward Hostname/IP: uptime-kuma (el nombre del container)
• Forward Port: 3001
• Activa: Websockets Support ← CRÍTICO
• SSL: Request a new SSL Certificate (Let’s Encrypt)

Modifica tu docker-compose.yml para conectar ambos containers:

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - uptime-kuma-data:/app/data
    networks:
      - proxy  # Misma red que Nginx Proxy Manager

networks:
  proxy:
    external: true  # Red creada por NPM

volumes:
  uptime-kuma-data:

Opción 2: Nginx config manual

Si usas Nginx directamente, esta es la configuración mínima:

server {
    listen 80;
    server_name uptime.tudominio.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name uptime.tudominio.com;

    ssl_certificate /etc/letsencrypt/live/uptime.tudominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/uptime.tudominio.com/privkey.pem;

    location / {
        proxy_pass http://uptime-kuma:3001;
        proxy_http_version 1.1;

        # Headers críticos para WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Los headers Upgrade y Connection son OBLIGATORIOS o Uptime Kuma no funcionará.

Opción 3: Traefik (Con labels)

Si usas Traefik como reverse proxy:

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - uptime-kuma-data:/app/data
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.uptime.rule=Host(`uptime.tudominio.com`)"
      - "traefik.http.routers.uptime.entrypoints=websecure"
      - "traefik.http.routers.uptime.tls.certresolver=letsencrypt"
      - "traefik.http.services.uptime.loadbalancer.server.port=3001"

networks:
  traefik:
    external: true

volumes:
  uptime-kuma-data:

Traefik maneja WebSocket automáticamente, no necesitas configuración extra.

Tipos de Monitores: Todos los Casos de Uso

Uptime Kuma soporta 9 tipos de monitores diferentes. Aquí está cada uno con ejemplos prácticos.

1. HTTP(S) Monitor

Uso: Websites, APIs REST, servicios web

Configuración:

• URL completa (https://ejemplo.com)
• HTTP Method: GET, POST, PUT, DELETE, HEAD, etc.
• Expected Status Codes: 200-299 (default) o custom
• Headers personalizados (Authorization, User-Agent, etc.)
• Body (JSON/Form data)
• Authentication (Basic Auth, Bearer Token)
• SSL Certificate Check
• Ignore TLS errors (para self-signed)

Ejemplo real – Monitorizar ElDiarioIA:

Monitor Name: ElDiarioIA Home
URL: https://www.eldiarioia.es
Method: GET
Heartbeat Interval: 60 seconds
Retries: 2
Expected Status: 200-299
Timeout: 48 seconds

Si el sitio devuelve 500, 503 o cualquier error, recibes alerta instantly.

2. HTTP(S) Keyword Monitor

Uso: Verificar que contenido específico existe (o NO existe) en una página

Casos de uso:

• Detectar errores visibles: Buscar “Error 500” o “Database connection failed”
• Verificar contenido crítico: Buscar “Comprar ahora” en e-commerce
• Monitorear cambios: Detectar si desapareció texto importante

Ejemplo – Detectar errores en WordPress:

Monitor Name: ElDiarioIA Error Check
URL: https://www.eldiarioia.es
Keyword: "El blog donde la IA y el humano aprenden juntos"
Invert Keyword: No (queremos que EXISTA)

Si el keyword desaparece → Algo rompió el sitio.

Ejemplo inverso – Detectar mensajes de error:

Monitor Name: API Error Detection
URL: https://api.ejemplo.com/health
Keyword: "error"|"failed"|"unavailable"
Invert Keyword: Yes (NO queremos que existan)

3. HTTP(S) JSON Query Monitor

Uso: APIs REST que devuelven JSON, validar respuestas específicas

Configuración:

• URL de API
• JSON Path query (sintaxis JSONPath)
• Expected value

Ejemplo – WordPress REST API:

Monitor Name: WordPress API Health
URL: https://www.eldiarioia.es/wp-json/wp/v2/posts?per_page=1
Expected Value: $.0.id
Condition: Exists

Valida que la API devuelve al menos 1 post. Si falla → API rota.

Ejemplo avanzado – Validar valor específico:

Monitor Name: n8n Webhook Status
URL: https://n8n.tudominio.com/webhook/healthcheck
JSON Path: $.status
Expected Value: "ok"

4. TCP Port Monitor

Uso: Servicios que NO son HTTP (databases, SSH, custom apps)

Ejemplos de puertos comunes:

• SSH: 22
• MySQL: 3306
• PostgreSQL: 5432
• Redis: 6379
• MongoDB: 27017
• SMTP: 25 / 587
• Minecraft: 25565

Ejemplo – Monitorear SSH de Proxmox:

Monitor Name: Proxmox SSH
Hostname: 192.168.1.10
Port: 22
Heartbeat Interval: 120 seconds

Si el puerto no responde → Servidor probablemente caído.

Ejemplo – Base de datos:

Monitor Name: PostgreSQL Main
Hostname: db.interno.local
Port: 5432

5. Ping (ICMP) Monitor

Uso: Verificar que un host está online a nivel de red (Layer 3)

Configuración:

• Hostname o IP
• Packet Count
• Acceptable Packet Loss %

Ejemplo – Gateway/Router:

Monitor Name: Router Principal
Hostname: 192.168.1.1
Packet Count: 5
Acceptable Loss: 0%

Ejemplo – Servidor Proxmox:

Monitor Name: Proxmox Host
Hostname: 192.168.1.10
Packet Count: 3
Acceptable Loss: 20%

Útil para detectar problemas de red incluso si los servicios están caídos.

6. DNS Monitor

Uso: Verificar que resoluciones DNS funcionan correctamente

Configuración:

• Hostname a resolver
• Resolver server (1.1.1.1 Cloudflare, 8.8.8.8 Google, o tu Pi-hole)
• Record Type: A, AAAA, CNAME, MX, TXT, NS, etc.
• Expected value (opcional)

Ejemplo – Verificar DNS principal:

Monitor Name: ElDiarioIA DNS Check
Hostname: www.eldiarioia.es
Resolver: 1.1.1.1
Type: A
Expected: (deja vacío para cualquier IP válida)

Ejemplo – Validar MX records (email):

Monitor Name: Email DNS
Hostname: eldiarioia.es
Resolver: 8.8.8.8
Type: MX

Crítico si gestionas tu propio email server.

7. Docker Container Monitor

Uso: Monitorear estado de containers Docker directamente

Configuración:

• Bind mount del Docker socket en tu docker-compose.yml
• Seleccionar container por nombre
• Expected state: Running

Docker Compose modificado:

version: '3.8'

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

Ejemplo – Monitorear Nginx Proxy Manager:

Monitor Name: Nginx Proxy Manager
Docker Container: nginx-proxy-manager
Docker Host: Local Docker (socket)
Expected State: Running

Si el container se cae, reinicia o entra en estado unhealthy → Alerta instantánea.

Múltiples containers:
Crea un monitor por cada container crítico:

• Plex/Jellyfin
• Home Assistant
• Pi-hole
• Portainer
• Vaultwarden
• Nextcloud

8. Push Monitor (Para Cron Jobs y Backups)

Uso: Servicios que TÚ NO puedes pollear (cron jobs, scripts de backup, tareas programadas)

Cómo funciona:

• Uptime Kuma genera URL única de push
• Tu script hace POST a esa URL cuando completa
• Si Uptime Kuma NO recibe POST en X tiempo → DOWN

Ejemplo – Script de backup diario:

#!/bin/bash
# backup-homelab.sh

set -e  # Para si hay error

# Tu backup
restic backup /home /var/www /etc

# Notificar a Uptime Kuma que completó OK
curl -fsS -m 10 --retry 3 https://uptime.tudominio.com/api/push/abc123def456

# Si el script falla ANTES del curl, Uptime Kuma detecta que no llegó el ping

Configuración en Uptime Kuma:

Monitor Name: Backup Diario
Type: Push
Heartbeat Interval: 1440 minutes (24 horas)
Push URL: https://uptime.tudominio.com/api/push/abc123def456

Si el backup no se ejecuta o falla → No llega el ping → Alerta.

Casos de uso:

• Backups programados
• Cron jobs críticos
• Scripts de limpieza/mantenimiento
• Procesos batch nocturnos
• Sincronizaciones de datos

9. Steam Game Server Monitor

Uso: Monitorear servidores de juegos Steam (Minecraft, CS:GO, etc.)

Configuración básica:

• Server IP
• Query port
• Game type

No lo cubro en profundidad porque está fuera del scope de homelabs típicos, pero está disponible.

Tabla Resumen: Qué Monitor Usar Cuándo

Configurar Notificaciones: Discord y Telegram

De nada sirve monitorear si no te enteras cuando algo cae. Uptime Kuma soporta 90+ servicios de notificaciones, pero los más populares en homelabs son Discord y Telegram.

Notificaciones Discord (Webhooks)

Ventajas:

• Gratis e ilimitado
• Notificaciones instantáneas
• Desktop + mobile
• Log histórico persistente
• Rich embeds con colores

Setup paso a paso:

1. Crear Webhook en Discord:

• Abre tu servidor Discord
• Click derecho en canal → Edit Channel → Integrations
• Webhooks → New Webhook
• Nombre: “Uptime Kuma”
• Copiar Webhook URL (se ve así: https://discord.com/api/webhooks/123456789/abcdefg...)

2. Configurar en Uptime Kuma:

• Settings (icono perfil arriba derecha) → Notifications
• Setup Notification → Discord
• Pegar Webhook URL
• Bot Display Name: “Uptime Monitor” (aparecerá en Discord con este nombre)
• Apply on All Existing Monitors (opcional, aplica a todos)
• Click Test (deberías recibir mensaje de prueba en Discord)
• Save

Ejemplo de mensaje que recibirás:

🔴 DOWN: ElDiarioIA Home
https://www.eldiarioia.es is DOWN
Time: 2025-11-03 10:30:00
Duration: Just now

Y cuando se recupera:

🟢 UP: ElDiarioIA Home
https://www.eldiarioia.es is back ONLINE
Downtime: 5 minutes

Notificaciones Telegram (Bot)

Ventajas:

• Más privado que Discord
• App mobile excelente
• Notificaciones push agresivas
• Sin servidores propios
• Gratis

Setup paso a paso:

1. Crear Bot de Telegram:

• Abre Telegram
• Busca @BotFather (bot oficial)
• Envía comando: /newbot
• Nombre del bot: “Uptime Kuma Monitor”
• Username del bot: mi_uptime_bot (debe terminar en bot)
• Copia el API Token (ej: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

2. Configurar en Uptime Kuma:

• Settings → Notifications → Setup Notification → Telegram
• Pegar Bot Token
• Envía cualquier mensaje a tu bot en Telegram (para iniciar conversación)
• Click Auto Get (al lado de Chat ID)
• Uptime Kuma detectará automáticamente tu Chat ID
• Test → Save

Ejemplo de mensaje:

🔴 ElDiarioIA Home is DOWN

URL: https://www.eldiarioia.es
Time: 2025-11-03 10:30:00

Configuración Óptima de Notificaciones

Recomendación para homelab:

• Discord: Todos los monitores → Canal #monitoring-logs

• Ventaja: Log histórico completo
• Desventaja: Puede ser ruidoso

• Telegram: Solo monitores críticos → Chat privado 1-on-1

• Servicios críticos: Proxmox, Router, Servicios públicos
• Ventaja: Notificaciones push agresivas, menos ruido

• Email: Resumen diario/semanal (opcional)

• Configurar SMTP
• Enviar solo 1x al día con status general

Evitar notification fatigue: No envíes TODAS las alertas a TODOS los canales. Prioriza y segmenta.

Otras Notificaciones Populares

Gotify (Self-hosted push):

• Instala Gotify server en Docker
• App Android con notificaciones offline
• 100% self-hosted (máxima privacidad)

Pushover ($5 one-time):

• App iOS/Android
• Sonidos custom por prioridad
• Muy confiable

Webhook (para n8n, Home Assistant, etc.):

URL: https://n8n.tudominio.com/webhook/uptime-kuma
Method: POST
Headers: Content-Type: application/json
Body: JSON con {{MONITOR_NAME}}, {{STATUS}}, {{MESSAGE}}

Crear Status Page Pública

Una de las mejores features de Uptime Kuma es poder crear status pages públicas (algo que UptimeRobot cobra $18/mes y Pingdom $59/mes).

Casos de uso:

• Mostrar uptime a clientes (SaaS, freelance)
• Transparencia para usuarios de tu servicio
• Status page interna para familia/compañeros de homelab

Paso a paso:

• Status Pages → Add Status Page
• Slug: homelab (URL será https://uptime.tudominio.com/status/homelab)
• Title: “Homelab Status – ElDiarioIA”
• Description: “Estado en tiempo real de servicios homelab”
• Theme: Dark (o Auto/Light)
• Select Monitors: Marca los que quieres mostrar públicamente
• Public: Activar (o dejar privado con password)
• Save

Customización avanzada:

Settings de Status Page:
- Custom CSS para branding
- Logo personalizado (URL a imagen)
- Footer text con links
- Google Analytics tracking ID
- Custom domain (CNAME)

Ejemplo de URL pública:

https://status.eldiarioia.es/

Muestra:

• ✅ Website: Online (99.8% uptime 30d)
• ✅ API: Online (100% uptime 30d)
• ⚠️ Demo Server: Degraded (2 incidents)
• 🔴 Test Service: Down (last 30 min)

Embed en tu sitio web:

<iframe src="https://uptime.tudominio.com/status/homelab"
        width="100%" height="600" frameborder="0"></iframe>

Caso de Uso Real: Monitorear Homelab Completo

Ahora que conoces todos los tipos de monitores, vamos a configurar un homelab completo con Uptime Kuma.

Infraestructura ejemplo:

• 1x Proxmox host (192.168.1.10)
• 1x Router/Firewall pfSense (192.168.1.1)
• Docker containers: Nginx Proxy Manager, Pi-hole, Home Assistant, Plex, Portainer, Vaultwarden
• Servicios externos: Website público, API

Configuración de monitores:

Capa 1: Red (Ping)

Monitor: Router Principal
Type: Ping
Host: 192.168.1.1
Interval: 120s
Tags: critical, network

Monitor: Proxmox Host
Type: Ping
Host: 192.168.1.10
Interval: 60s
Tags: critical, infrastructure

Capa 2: Infraestructura (TCP + HTTP)

Monitor: Proxmox SSH
Type: TCP Port
Host: 192.168.1.10
Port: 22
Interval: 300s
Tags: infrastructure

Monitor: Proxmox Web UI
Type: HTTP(S)
URL: https://192.168.1.10:8006
Interval: 300s
Ignore TLS: Yes (self-signed)
Tags: infrastructure

Capa 3: Containers Docker

# Asegúrate de tener docker socket montado
volumes:
  - /var/run/docker.sock:/var/run/docker.sock:ro

Monitor: Nginx Proxy Manager
Type: Docker Container
Container: nginx-proxy-manager
Interval: 120s
Tags: critical, proxy

Monitor: Pi-hole
Type: Docker Container
Container: pihole
Interval: 120s
Tags: critical, dns

Monitor: Home Assistant
Type: Docker Container
Container: homeassistant
Interval: 120s
Tags: homelab, automation

Monitor: Plex
Type: Docker Container
Container: plex
Interval: 300s
Tags: media

Monitor: Vaultwarden
Type: Docker Container
Container: vaultwarden
Interval: 120s
Tags: critical, security

Capa 4: Servicios Web (HTTP)

Monitor: Pi-hole Admin
Type: HTTP(S)
URL: http://192.168.1.10:8080/admin
Interval: 300s
Tags: homelab, dns

Monitor: Home Assistant UI
Type: HTTP(S)
URL: http://192.168.1.10:8123
Keyword: "Home Assistant"
Interval: 300s
Tags: homelab

Monitor: Portainer
Type: HTTP(S)
URL: https://portainer.tudominio.com
Interval: 600s
Tags: homelab, management

Capa 5: Servicios Públicos

Monitor: Website ElDiarioIA
Type: HTTP(S)
URL: https://www.eldiarioia.es
Method: GET
Expected Status: 200-299
Interval: 60s
Tags: critical, public, website

Monitor: WordPress API
Type: HTTP(S) JSON Query
URL: https://www.eldiarioia.es/wp-json/wp/v2/posts?per_page=1
JSON Path: $[0].id
Condition: Exists
Interval: 300s
Tags: critical, api

Capa 6: DNS

Monitor: DNS Principal
Type: DNS
Hostname: www.eldiarioia.es
Resolver: 1.1.1.1
Type: A
Interval: 3600s
Tags: infrastructure, dns

Capa 7: Backups (Push)

Monitor: Backup Proxmox Diario
Type: Push
Heartbeat: 1440 min (24h)
Tags: critical, backup

# En tu script de backup:
#!/bin/bash
/usr/bin/proxmox-backup-client backup ...
curl -fsS https://uptime.tudominio.com/api/push/PUSH_URL_UNICA

Total: ~20 monitores para homelab completo.

Configuración de alertas:

• Telegram: Solo tags critical (Router, Proxmox, Website, Vaultwarden)
• Discord: Todos los monitores → Canal #homelab-monitoring

Resultado:

• Detectas problemas ANTES de notarlos manualmente
• Histórico de uptime de cada servicio
• Identificas servicios problemáticos (muchos downs)
• Status page compartible con familia/compañeros

Integraciones Avanzadas

Integración con Home Assistant

Puedes integrar Uptime Kuma con Home Assistant usando webhooks para automatizaciones inteligentes. Si quieres aprender más sobre Home Assistant, revisa nuestra guía para automatizar tu casa desde cero.

Ejemplo: Reiniciar Plex automáticamente si cae

# configuration.yaml
automation:
  - alias: "Reiniciar Plex si down"
    trigger:
      platform: webhook
      webhook_id: uptime_kuma_plex_down
      allowed_methods:
        - POST
    condition:
      - condition: template
        value_template: "{{ trigger.json.monitor == 'Plex' and trigger.json.status == 'down' }}"
    action:
      - service: shell_command.restart_plex

shell_command:
  restart_plex: "docker restart plex"

Configura Uptime Kuma para enviar webhook a Home Assistant cuando Plex cae → Home Assistant lo reinicia automáticamente.

Integración con n8n

Crea workflows complejos con n8n para automatizar respuestas:

Ejemplo: Crear GitHub issue si servicio crítico cae

Webhook (Uptime Kuma)
  → Filter (solo monitores con tag "critical")
  → GitHub (crear issue con detalles)
  → Discord (notificar al equipo)
  → HTTP Request (intentar restart automático vía API)

Exportar métricas a Grafana

Para visualizaciones avanzadas:

• Exporta data de Uptime Kuma a Prometheus/InfluxDB
• Importa a Grafana
• Crea dashboards custom con:
• Uptime % por servicio
• Response time trends
• Downtime incidents timeline
• SLA compliance

(Requiere setup adicional fuera del scope de este artículo)

Troubleshooting: Errores Comunes

Error: “Database is locked”

Causa: Estás usando volumen NFS/SMB (no soporta POSIX file locks)

Solución:

volumes:
  uptime-kuma-data:
    driver: local  # NO usar NFS driver

Usa local storage, block storage o relocate a volumen sin red.

WebSocket connection failed en navegador

Causa: Reverse proxy sin headers WebSocket

Solución Nginx:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Solución Nginx Proxy Manager:
Activa “Websockets Support” en configuración de proxy host.

High CPU usage (>80% constant)

Causas posibles:

• Demasiados monitores con intervalos <60s
• Monitor con timeout muy alto (48s default)
• Hardware insuficiente

Soluciones:

• Aumenta intervalos a 120s para monitores no críticos
• Reduce timeout a 20s para servicios locales
• Elimina monitores redundantes
• Upgrade a VPS con más vCPU

Notificaciones no llegan

Debugging:

• Settings → Notifications → Click “Test” en tu notificación
• Si falla: Verifica logs con docker logs uptime-kuma
• Discord: Verifica Webhook URL correcta (cópiala de nuevo)
• Telegram: Asegúrate de haber enviado mensaje al bot primero
• Email: Verifica SMTP settings (usa port 587 TLS para Gmail)

Backup y Restauración

Backup manual del volumen Docker:

# Crear backup
docker run --rm \
  -v uptime-kuma-data:/data \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/uptime-kuma-backup-$(date +%Y%m%d).tar.gz /data

# Restaurar backup
docker run --rm \
  -v uptime-kuma-data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/uptime-kuma-backup-20251103.tar.gz -C /

Backup automático con script + push monitor:

#!/bin/bash
# backup-uptime-kuma.sh

BACKUP_DIR="/backups/uptime-kuma"
DATE=$(date +%Y%m%d)

docker run --rm \
  -v uptime-kuma-data:/data \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/uptime-kuma-$DATE.tar.gz /data

# Notificar a Uptime Kuma
curl -fsS https://uptime.tudominio.com/api/push/abc123

# Limpiar backups antiguos (>30 días)
find $BACKUP_DIR -name "uptime-kuma-*.tar.gz" -mtime +30 -delete

Mejores Prácticas de Configuración

Intervalos Recomendados

Regla general: No uses intervalos <60s a menos que sea absolutamente crítico (y tu servidor lo aguante).

Configuración de Retries

Retries: 2-3
Retry Interval: 60 seconds

Evita false positives por blips temporales de red. Con 2 retries, necesitas 3 fallos consecutivos para marcar como DOWN.

Timeout Settings

HTTP/HTTPS: 20-30s (servicios locales), 48s (servicios externos)
TCP: 30s
Ping: 10s

Timeout muy alto → Detección lenta de problemas
Timeout muy bajo → False positives por latencia

Organización con Tags

Usa tags estratégicos:

critical - Requiere acción inmediata
homelab - Infraestructura local
public - Servicios de cara al público
infrastructure - Red, router, hosts físicos
backup - Push monitors de backups
media - Plex, Jellyfin, etc.
automation - Home Assistant, n8n
security - Vaultwarden, Authelia

Ventaja: Filtra fácilmente en dashboard, configura notificaciones por tag.

Seguridad

Checklist:

• ✅ Activa 2FA (TOTP)
• ✅ Usa reverse proxy con HTTPS
• ✅ Contraseña fuerte para admin
• ✅ Firewall: Solo puerto 443 expuesto
• ✅ Status page: Solo muestra info que quieres pública
• ✅ Rotación de API tokens (si usas API)

NO expongas puerto 3001 directamente a internet (sin HTTPS ni autenticación).

Preguntas Frecuentes (FAQs)

¿Qué es Uptime Kuma?

Uptime Kuma es una herramienta open-source self-hosted para monitorear uptime de servicios web, APIs, servidores y containers Docker. Ofrece interfaz moderna, 90+ notificaciones integradas y status pages públicas, todo gratis. Es la alternativa self-hosted a servicios como UptimeRobot o Pingdom.

¿Uptime Kuma es realmente gratis?

Sí, el software es 100% gratis (licencia MIT open-source). El único costo es el hosting: necesitas un VPS (~$4-5/mes) o puedes correrlo en tu homelab existente sin costo adicional. No hay límites de monitores, notificaciones ni features ocultas detrás de paywall.

¿Uptime Kuma vs UptimeRobot: cuál es mejor?

Uptime Kuma es mejor si: quieres control total, muchos monitores (>50), intervalos <5 minutos, monitoreo de Docker containers, y te sientes cómodo con Docker/Linux. UptimeRobot es mejor si: solo necesitas monitorear pocos servicios externos (<50), no quieres mantener infraestructura, o necesitas multi-location monitoring inmediato. Para homelabs, Uptime Kuma gana por costo ($5 vs $28/mes para 200 monitores) y flexibilidad.

¿Cómo instalar Uptime Kuma con Docker?

Tres pasos: 1) Crea carpeta y archivo docker-compose.yml con la config oficial, 2) Ejecuta docker compose up -d, 3) Accede a http://localhost:3001 y crea cuenta admin. El proceso completo toma 5 minutos. Ver sección “Instalación con Docker Compose” arriba para configuración completa.

¿Qué tipos de monitores soporta Uptime Kuma?

Soporta 9 tipos: HTTP(S), HTTP(S) Keyword, HTTP(S) JSON Query, TCP Port, Ping (ICMP), DNS, Docker Container, Push (para cron jobs), y Steam Game Server. Esto cubre prácticamente cualquier servicio: websites, APIs, databases, SSH, containers, backups programados, etc.

¿Cómo configurar notificaciones Discord en Uptime Kuma?

1) En Discord: Server Settings → Integrations → Webhooks → Create Webhook, copia la URL. 2) En Uptime Kuma: Settings → Notifications → Discord, pega Webhook URL, elige nombre del bot, Test, Save. Las notificaciones aparecen instantáneamente en tu canal Discord con formato colorido indicando UP (verde) o DOWN (rojo).

¿Puedo monitorear containers Docker con Uptime Kuma?

Sí, Uptime Kuma tiene soporte nativo para Docker. Debes bind mount el socket Docker (/var/run/docker.sock:/var/run/docker.sock:ro) en tu docker-compose.yml. Luego puedes crear monitores tipo “Docker Container” que detectan si containers están Running, Stopped, Restarting o Unhealthy. Ideal para homelabs.

¿Cómo crear una status page pública en Uptime Kuma?

Settings → Status Pages → Add Status Page. Elige slug (URL), título, descripción, selecciona qué monitores mostrar, customiza tema (dark/light), y publica. La URL será https://tu-dominio.com/status/slug. Puedes añadir custom CSS, logo, footer, y embedear en tu sitio web con iframe. Todo incluido gratis (vs $18-59/mes en otras plataformas).

¿Uptime Kuma consume muchos recursos?

No. Con 50-100 monitores: ~200MB RAM, <5% CPU en 1 vCPU. Un VPS de $4/mes (512MB RAM, 1 vCPU) es suficiente. Para 500+ monitores, considera 2GB RAM. El consumo depende de intervalos (intervalos <60s aumentan CPU) y número de monitores. Es muy eficiente comparado con alternativas.

¿Cómo hacer backup de Uptime Kuma?

Método manual: docker run --rm -v uptime-kuma-data:/data -v $(pwd):/backup ubuntu tar czf /backup/uptime-kuma-backup.tar.gz /data. Método automático: crea script que hace backup del volumen Docker y usa push monitor para verificar que el backup se ejecutó. Los datos viven en /app/data (SQLite database + config). Ver sección Troubleshooting para comandos completos.

¿Uptime Kuma funciona con reverse proxy?

Sí, pero necesitas configuración especial porque usa WebSocket. En Nginx: añade headers Upgrade y Connection "upgrade". En Nginx Proxy Manager: activa “Websockets Support”. En Traefik: funciona automáticamente sin config extra. Sin estos headers, la UI no carga correctamente.

¿Qué es un push monitor y cuándo usarlo?

Push monitor es un monitor donde TÚ envías notificación a Uptime Kuma (inverso). Uptime Kuma genera URL única, tu script hace POST cuando completa. Si no recibe POST en X tiempo → DOWN. Úsalo para: cron jobs, backups programados, scripts de mantenimiento, cualquier tarea que TÚ no puedes pollear activamente. Ejemplo: script de backup nocturno que avisa cuando termina OK.

¿Uptime Kuma soporta 2FA?

Sí, soporta 2FA con TOTP (Time-based One-Time Password) compatible con Google Authenticator, Authy, 1Password, etc. Settings → Security → Enable Two-Factor Auth → Escanea QR con tu app → Guarda backup codes. Muy recomendado activarlo si expones Uptime Kuma a internet.

¿Puedo integrar Uptime Kuma con Home Assistant?

Sí, vía webhooks. Configura webhook notification en Uptime Kuma hacia tu Home Assistant. Luego crea automations que reaccionan a eventos (ej: si Plex cae → reiniciar container automáticamente). También puedes usar integraciones custom vía HACS. Muy potente para automatización de respuestas a incidents.

¿Cuántos monitores puedo crear en Uptime Kuma?

Ilimitados. No hay límite artificial de software. El único límite es tu hardware (CPU/RAM). Un VPS básico ($4/mes) maneja fácilmente 100-200 monitores. Para 500+, upgrade a 2 vCPU / 2 GB RAM. Compara con UptimeRobot free (50 monitores) o Pingdom ($85/mes para 200 monitores).

Conclusión: ¿Vale la Pena Uptime Kuma?

Después de configurar Uptime Kuma, la respuesta es SÍ rotundo, especialmente si:

✅ Gestionas homelab con múltiples servicios
✅ Quieres saber CUÁNDO se cae algo (no descubrirlo horas después)
✅ Te importa la privacidad (self-hosted)
✅ Tienes conocimientos básicos Docker/Linux
✅ Buscas alternativa gratis a Pingdom/UptimeRobot

ROI real:

• Tiempo: 30 minutos instalación inicial + 15 min configuración monitores = inversión única de 45 minutos
• Costo: $0 si ya tienes servidor, o $4-5/mes VPS básico
• Ahorro vs UptimeRobot: $23/mes ($276/año) para 200 monitores
• Ahorro vs Pingdom: $80/mes ($960/año) para 200 monitores

Beneficios intangibles:

• Detección proactiva de problemas (vs descubrirlos reactivamente)
• Métricas de uptime histórico (identificas servicios problemáticos)
• Status page profesional para clientes/usuarios
• Paz mental (sabes que recibirás alerta si algo falla)

Limitaciones honestas:

• Requiere mantenimiento básico (updates Docker, backups)
• No incluye multi-location monitoring out-of-box (vs UptimeRobot)
• Soporte solo comunidad GitHub (vs soporte pago enterprise)
• Necesitas conocimientos técnicos mínimos

Para la mayoría de homelabbers, desarrolladores indie, y pequeños proyectos SaaS, Uptime Kuma es la mejor opción en 2025. La combinación de features modernas, precio (gratis) y control total es imbatible.

Próximos pasos:

• Instala Uptime Kuma siguiendo la guía de Docker Compose arriba
• Configura tus primeros 5 monitores críticos
• Añade notificaciones Discord/Telegram
• Crea status page pública (si aplica)
• Configura backup automático con push monitor

¿Quieres más guías de homelab? Revisa nuestros artículos sobre Tailscale para acceso remoto sin abrir puertos, Docker Compose para homelab completo, y cómo montar Proxmox desde cero.

¿Tienes dudas o problemas configurando Uptime Kuma? Déjanos un comentario abajo.