Uptime Kuma es el monitor gratuito y autoalojado que sondea tus sitios y servidores y da la voz de alarma cuando se caen, y ponerlo en marcha lleva unos cinco minutos. La vía rápida: ejecuta un contenedor de Docker, abre el puerto 3001 en un navegador, crea una cuenta de administrador y añade tu primera comprobación. Esta guía explica cómo configurar Uptime Kuma correctamente en 2026 — no solo la instalación, sino las dos cosas que la mayoría de los tutoriales pasan por alto: dónde ejecutarlo de verdad y cómo asegurarte de que las alertas te lleguen cuando importa.
La versión que importa ahora es Uptime Kuma 2. La línea 2.x tiene licencia MIT, incluye una imagen de Docker sin privilegios de root, trasladó la interfaz a Vue 3 y añadió MariaDB como opción junto al SQLite predeterminado. Para una única instancia que vigile un puñado de servicios, los valores predeterminados son todo lo que necesitas.
¿Qué es Uptime Kuma y por qué ejecutar el tuyo propio?
Uptime Kuma es un monitor de disponibilidad y estado de código abierto: comprueba si un sitio web, una API, un contenedor o un puerto responde, registra el tiempo de respuesta y lanza una notificación en el momento en que una comprobación falla. Piénsalo como un sustituto autoalojado de servicios de pago como UptimeRobot, Pingdom o Better Stack — salvo que lo ejecutas tú, así que no hay cuota mensual, ni límite de monitores, y tu lista de objetivos nunca sale de tu propia máquina. Admite comprobaciones de HTTP(S), puerto TCP, ping, DNS, palabra clave y contenedor de Docker, publica páginas de estado públicas y, en la versión 2, se comunica con más de 78 canales de notificación incluidos Telegram, Discord, Slack y correo electrónico. La contrapartida es la de todo autoalojamiento: eres responsable de la disponibilidad de tu propio monitor de disponibilidad. Eso es manejable, y el resto de esta guía trata sobre todo de hacerlo fiable.
Uptime Kuma de un vistazo
| Atributo | Detalle |
|---|---|
| Licencia / coste | MIT, gratis para siempre |
| Instalación | Un único contenedor de Docker |
| Puerto de la interfaz web | 3001 |
| Almacenamiento | SQLite (predeterminado) o MariaDB |
| Intervalo de comprobación predeterminado | 60 segundos |
| Tipos de monitor | HTTP(S), TCP, ping, DNS, palabra clave, Docker |
| Notificaciones | Más de 78 canales (Telegram, Discord, Slack, correo…) |
| Páginas de estado | Sí, con un editor WYSIWYG |
| Acceso predeterminado | Ninguno — creas el administrador en el primer arranque |
Lo que necesitas antes de empezar
Necesitas una máquina que pueda ejecutar Docker y permanecer encendida: un VPS económico, un equipo de homelab o un NAS, todos sirven. La única regla que condiciona todo lo demás — no ejecutes Uptime Kuma en el mismo servidor que se supone que debe vigilar. Si la máquina que aloja tu aplicación se viene abajo, también lo hace el monitor que debería avisarte, y te enteras por un cliente enfadado en su lugar. Un VPS de 4–5 USD al mes en una región distinta (o directamente de otro proveedor) es la configuración estándar. Si vas a levantar un servidor nuevo para esto, fortifícalo primero con nuestra checklist de la primera hora segura de un VPS antes de exponer nada.
También te conviene tener instalados Docker y el plugin de Compose y — opcionalmente — un nombre de dominio si piensas acceder al panel por HTTPS en lugar de por una IP y un puerto en crudo.
Cómo configurar Uptime Kuma con Docker
La versión de un solo comando, directamente de la documentación del propio proyecto, te deja funcionando de inmediato:
docker run -d --restart=always \
-p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:2
Para cualquier cosa que pienses conservar, usa Compose en su lugar para que la configuración viva en un archivo que puedas respaldar y versionar. Guarda esto como docker-compose.yml:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
volumes:
- uptime-kuma:/app/data
ports:
- "3001:3001"
restart: always
volumes:
uptime-kuma:
Luego levántalo con docker compose up -d. En cualquiera de los dos casos, lo importante es el volumen: uptime-kuma:/app/data es donde vive cada monitor, ajuste y punto del historial. Pierde ese volumen y pierdes toda tu configuración, así que es lo que debes respaldar. Un detalle a tener en cuenta según la documentación — no pongas ese directorio de datos en NFS; la base de datos integrada no lo tolera y se corromperá.
Ahora abre http://<your-server-ip>:3001 en un navegador. No hay nombre de usuario ni contraseña predeterminados — la primera pantalla te pide crear la cuenta de administrador, así que elige aquí una contraseña robusta y guárdala en tu gestor. Con eso queda toda la instalación.
Añadir tu primer monitor
Haz clic en Add New Monitor y elige un tipo. Para un sitio web, elige HTTP(s), pega la URL completa y deja el intervalo de comprobación en 60 segundos para empezar. Merece la pena configurar unos cuantos ajustes de forma deliberada en lugar de aceptarlos sin más:
- Retries — ajústalo a 2 o 3 para que un solo paquete perdido no te despierte a las 3 de la madrugada. Un monitor solo pasa a estar «caído» después de agotar los reintentos.
- Monitor de palabra clave — en lugar de fiarte de un código de estado 200, haz que Uptime Kuma confirme que una palabra como «login» o «checkout» aparece realmente en el cuerpo de la página. Un servidor puede devolver 200 mientras renderiza una página de error, y esto lo detecta.
- Modo invertido (upside-down) — invierte la lógica para que «arriba» signifique que la comprobación falla, útil para confirmar que algo no es accesible.
Añade un monitor para cada servicio público y una comprobación TCP o de ping para el propio host subyacente. Esa separación te dice si lo que está caído es la aplicación o toda la máquina.
Conectar alertas que de verdad te lleguen
Un monitor sin notificación no es más que un panel que nadie mira. Ve a Settings → Notifications → Setup Notification, elige un canal, y este es el paso que la gente se salta: envía la notificación de prueba y confirma que llega antes de fiarte de ella. Un token de Telegram mal configurado o una contraseña de SMTP que falla en silencio es peor que no tener monitorización, porque darás por hecho que estás cubierto.
Configura al menos dos canales sobre infraestructura distinta — por ejemplo Telegram o Discord como aviso push instantáneo, más el correo electrónico como respaldo. Si tu vía de alerta depende solo del correo y tu proveedor de correo tiene un mal día al mismo tiempo que tu servidor, no recibes nada. Después de crear la notificación, actívala dentro de los ajustes de cada monitor para que quede realmente vinculada; una notificación que existe pero no está enlazada a ningún monitor no hace nada.
¿Dónde deberías ejecutar Uptime Kuma? La parte que la mayoría de las guías omiten
Instalar Uptime Kuma es fácil; ubicarlo bien es lo que separa una configuración de monitorización real de un juguete. La idea central: el monitor tiene que poder fallar de forma independiente de aquello que monitoriza. En la práctica eso se traduce en tres hábitos.
Primero, alójalo fuera de la máquina — un VPS aparte, idealmente de otro proveedor o región distinta de tu stack de producción, para que un único incidente de centro de datos no pueda tumbar ambos. Segundo, mantén el panel en sí privado. Expone todo el mapa de tu infraestructura, así que no dejes el puerto 3001 abierto a internet; ponlo detrás de un proxy inverso autenticado o accede a él por una red privada. Nuestra guía sobre Tailscale como VPN de malla privada cubre el enfoque de cero puertos abiertos. Tercero, si publicas una página de estado pública para tus clientes, aloja también la instancia de esa página en un lugar neutral — una página de estado que se cae junto con tu sitio desbarata su propio propósito.
Ponlo detrás de HTTPS, respáldalo y mantenlo al día
Tres pasos de remate convierten la instalación en algo que puedes dejar funcionando durante un año:
- HTTPS. Acceder a un panel de monitorización por HTTP plano sobre una IP en crudo está bien durante cinco minutos y está mal para un uso permanente. Termina el TLS con un proxy inverso para obtener un certificado real y un nombre de host limpio — nuestra guía de Caddy como proxy inverso hace HTTPS automático en unas pocas líneas.
- Copias de seguridad. Todo está en el volumen
uptime-kuma, así que haz snapshots de forma programada; el mismo patrón de nuestra guía de copias de seguridad de volúmenes de Docker se aplica directamente. Prueba una restauración una vez para saber que funciona. - Actualizaciones. Uptime Kuma publica versiones de mantenimiento frecuentes con correcciones y nuevas integraciones de notificación. Descarga periódicamente la última imagen
:2, o automatízalo — con cuidado — con el enfoque de nuestra guía de autoactualización con Watchtower.
Preguntas frecuentes
¿Cuál es el acceso predeterminado de Uptime Kuma?
No hay ninguno. A diferencia de muchos appliances, Uptime Kuma se distribuye sin nombre de usuario ni contraseña predeterminados. En la primera visita al puerto 3001 te pide crear la cuenta de administrador, así que las credenciales son las que tú establezcas. Si te quedas fuera, restableces el acceso entrando en el volumen de datos del contenedor en lugar de usar unos valores de fábrica.
¿Es Uptime Kuma realmente gratuito?
Sí. Es de código abierto bajo la licencia MIT, sin nivel de pago, sin límite de monitores y sin necesidad de cuenta. Tus únicos costes son el servidor en el que lo ejecutas y tu tiempo. Esa es la razón principal por la que es la opción autoalojada por defecto frente a UptimeRobot o Pingdom para quienes ya gestionan su propia infraestructura.
¿Puede Uptime Kuma monitorizar contenedores de Docker?
Sí. Junto con las comprobaciones de HTTP, TCP, ping y DNS, cuenta con un monitor de Docker dedicado que vigila el estado del contenedor a través del socket de Docker, de modo que puedes recibir alertas cuando un contenedor concreto se detiene, y no solo cuando su puerto expuesto deja de responder.
¿Necesita Uptime Kuma una base de datos?
No una aparte para una configuración normal. Almacena todo en una base de datos SQLite integrada dentro del volumen /app/data de forma predeterminada. La versión 2 añadió soporte opcional de MariaDB para despliegues grandes o de alta frecuencia, pero la mayoría de los usuarios de una única instancia no lo necesitan nunca.
¿Con qué frecuencia comprueba Uptime Kuma un monitor?
El intervalo predeterminado es de 60 segundos, y puedes ajustar cada monitor hasta un mínimo de 20 segundos o hasta un máximo de horas. Combina un intervalo corto con un número de reintentos de 2–3 para que los pequeños cortes de red no disparen falsas alarmas.
Sources
- Uptime Kuma — repositorio de GitHub — licencia MIT, versión actual 2, comando oficial de Docker
- Uptime Kuma — sitio oficial — instalación de Docker en una línea y detalles de puerto/volumen
- Uptime Kuma — Cómo instalar (wiki) — opciones de alojamiento con Docker, Compose y un solo comando
- LinuxToday — Uptime Kuma 2.0 llega con soporte de MariaDB y renovación de la interfaz — imagen sin root, Vue 3, almacenamiento SQLite/MariaDB
- Tech Edu Byte — Uptime Kuma 2.1 notificaciones y estabilidad — notas de la reciente versión 2.1 y mejoras de estabilidad
- Better Stack — Guía completa de monitorización con Uptime Kuma — creación de monitores, notificaciones y páginas de estado
Waqas Ahmed Waseer
Waqas Ahmed Waseer es desarrollador y creador de automatizaciones con más de 8 años construyendo sistemas en producción que usan más de 100.000 personas. Crea SaaS multiinquilino a medida, automatización con IA (n8n, flujos LLM, bots de WhatsApp) e infraestructura de hosting (WHM/cPanel, CloudLinux), y es el creador de WaSphere, FlowMaticX y la marca de hosting WaseerHost. Más de 100 proyectos entregados para pymes, agencias y startups financiadas.
