Una pequeña tienda online de Konya tiene Uptime Kuma en un VPS (un servidor virtual alquilado) del mismo centro de datos que su servidor web, y el panel lleva tres días en verde. El lunes, el buzón de soporte dice otra cosa: los clientes con datos móviles no pueden cargar la página de pago y un distribuidor en Alemania no consigue abrir el sitio. El fallo está en algún punto del camino hacia el sitio, como un problema de enrutamiento en una red o una regla de bloqueo geográfico demasiado amplia. El monitor estaba al lado del sitio, así que no vio nada de esto.
Esta guía explica qué significa en horas un 99,9 % de uptime, qué hace Uptime Kuma, qué tipo de monitor elegir y cómo instalarlo con Docker. Después muestra por qué comprobar desde un solo lugar deja un punto ciego, cómo enviar las comprobaciones de un monitor a través de un proxy HTTP o SOCKS5 y cuánto tráfico consume eso.
¿Qué es el uptime y qué significa un 99,9 % de uptime?
El uptime (tiempo de actividad) es la parte del tiempo en que un servicio estuvo accesible durante un periodo medido; el downtime (tiempo de inactividad) es el resto. No es el comando uptime de Linux, que muestra cuánto tiempo lleva encendida una máquina. Un año de 365 días tiene 8.760 horas, y un 99,9 % deja el 0,1 % de ellas, 8,76 horas, para las caídas. Las calculadoras que muestran 8 horas 45 minutos 57 segundos cuentan el año como 365,25 días.
| Uptime | Caída por año (365 días) | Por mes de 30 días | Por día |
|---|---|---|---|
| 99 % | 87,6 horas | 7 h 12 min | 14 min 24 s |
| 99,5 % | 43,8 horas | 3 h 36 min | 7 min 12 s |
| 99,9 % | 8 h 45 min 36 s | 43 min 12 s | 1 min 26 s |
| 99,95 % | 4 h 22 min 48 s | 21 min 36 s | 43 s |
| 99,99 % | 52 min 34 s | 4 min 19 s | 8,6 s |
Una garantía de uptime es este objetivo escrito en un acuerdo de nivel de servicio (SLA). El libro de SRE de Google describe dos maneras de medirlo: la parte del tiempo en que un sistema estuvo activo y la parte de las peticiones que tuvieron éxito (Embracing Risk).
¿Qué es Uptime Kuma y para qué sirve?
Uptime Kuma es una herramienta de supervisión creada por Louis Lam y publicada con licencia MIT. La instalas en tu propio servidor, la abres en el navegador y añades monitores; cada monitor es una dirección o un servicio que se comprueba. El repositorio del proyecto tenía más de 90.000 estrellas en septiembre de 2026, cuando la versión vigente era la 2.5.5.
A diferencia de un servicio alojado, guarda el historial de comprobaciones y las claves de notificación en tu servidor y no limita el número de monitores. A cambio, tú mantienes ese servidor en marcha, y las comprobaciones salen desde donde funciona. También ofrece Páginas de estado públicas, ventanas de Mantenimiento que pausan las alertas y una interfaz en más de 40 idiomas.
¿Cómo comprueba Uptime Kuma un sitio?
Cada monitor repite el mismo ciclo (los nombres de los campos son los de la interfaz en español):
- Se cumple el intervalo. El Intervalo de latido es de 60 segundos por defecto. La petición lleva el User-Agent
Uptime-Kuma/2.5.5, así que puedes encontrarla en los registros de tu servidor. - Espera. Si no llega respuesta dentro del Tiempo de espera máximo de petición, 48 segundos por defecto, la comprobación falla.
- Lee la respuesta. El código de estado debe estar dentro de Códigos de estado aceptados,
200-299por defecto (códigos de estado HTTP). Un monitor de palabra clave también busca tu palabra en la página, distinguiendo mayúsculas y minúsculas. - Reintenta. Con Reintentos por encima de 0, una comprobación fallida se repite con el Intervalo de reintento de latido. Los monitores nuevos empiezan en 0, así que un solo paquete perdido envía una alerta.
- Avisa. Cuando se agotan los reintentos, el monitor pasa a Caído (DOWN) y los canales que añadiste en Ajustes > Notificaciones reciben un mensaje; cuando una comprobación vuelve a pasar, pasa a Funcional (UP).
- Registra. La página del monitor muestra el uptime de 24 horas, 30 días y 1 año.
La Notificación de Caducidad del Certificado está desactivada en los monitores nuevos. Actívala en los sitios HTTPS: Let's Encrypt empezó a ofrecer en mayo de 2026 certificados de 45 días para quien los solicite y prevé certificados de 64 días por defecto a partir de febrero de 2027 (Let's Encrypt), así que las renovaciones llegan más a menudo.
¿Qué tipo de monitor debes elegir?
Uptime Kuma 2.5.5 tiene unos treinta tipos de monitor. La mayoría de los sitios necesitan estos:
| Tipo de monitor | Qué confirma | ¿A través de un proxy? | Cuándo elegirlo |
|---|---|---|---|
| HTTP(s) | El servidor responde con un código de estado aceptado | Sí | Una pequeña página de salud |
| HTTP(s) - Palabra clave | La página contiene una palabra que esperas | Sí | Pago, inicio de sesión |
| HTTP(s) - Consulta Json | Una respuesta de API contiene el valor esperado | Sí | Endpoints de API |
| TCP Port, Ping, DNS | Un puerto está abierto, un host responde, un registro es correcto | No | Base de datos, servidor de correo, DNS |
| Push | Una tarea programada informa de que se ejecutó | No hace falta | Copias de seguridad, tareas cron |
| Globalping | Ping, HTTP o DNS desde una sonda de la comunidad | No, funciona desde la ubicación que escribes | Amplia cobertura geográfica |
| UptimeRobot (servicio alojado, para comparar) | HTTP, palabra clave, puerto y ping desde los servidores del servicio | No; los planes de pago eligen entre cuatro regiones (septiembre de 2026) | Nada que instalar |
HTTP(s) por sí solo demuestra únicamente que el servidor respondió. Incluso una página de mantenimiento o una plantilla rota pueden responder 200 y contar como UP. Un monitor de palabra clave que busca el texto del botón de pago detecta ambos casos, e Invertir palabra clave avisa cuando aparece una palabra como «mantenimiento». Una página de salud es una dirección corta que añade tu desarrollador y que responde «ok» cuando la aplicación y la base de datos responden.
Nivel avanzado: cómo instalar Uptime Kuma con Docker
Necesitas un VPS con Linux o un servidor doméstico con Docker, distinto de la máquina en la que funciona el sitio. El comando del README del proyecto:
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2-dlo ejecuta en segundo plano y--restart=alwayslo vuelve a arrancar tras un fallo o un reinicio.-p 3001:3001publica el puerto por defecto, el 3001.-v uptime-kuma:/app/dataguarda la base de datos en un volumen de Docker, que se conserva cuando se elimina el contenedor (volúmenes de Docker). El README indica que las carpetas de red (NFS) no son compatibles.louislam/uptime-kuma:2sigue la serie 2.x; el 25 de septiembre de 2026 apuntaba a la 2.5.5.
Con Docker Compose, descarga el compose.yaml oficial en una carpeta vacía y ejecuta docker compose up -d; guarda los datos en una carpeta local ./data. Después abre http://ip-de-tu-servidor:3001, elige el idioma y una base de datos (SQLite basta para una instalación pequeña), crea la cuenta de administrador y haz clic en Añadir nuevo monitor. Para actualizar, descarga la imagen nueva, elimina el contenedor y vuelve a ejecutar el comando; el volumen conserva tus monitores.
Abrir el panel en tu propio dominio con HTTPS es tarea de un reverse proxy (proxy inverso) como nginx o Caddy, que debe pasar las cabeceras Upgrade y Connection para WebSocket; la wiki del proyecto tiene ejemplos. Las dos direcciones del proxy se comparan en Forward proxy y reverse proxy.
¿Qué se pierde al supervisar desde un solo lugar?
Un monitor en el mismo centro de datos que el sitio demuestra que el servidor funciona, no que los clientes lleguen a él. Se le escapa:
- Un problema de enrutamiento en una red: los clientes de un proveedor no llegan al sitio.
- Un DNS que cambia según la región: un registro erróneo en un servidor DNS solo afecta a sus usuarios.
- Una regla de bloqueo geográfico demasiado amplia: una regla pensada para un país también bloquea otro.
- Un servidor de la CDN que devuelve errores: una CDN sirve el sitio desde muchos servidores, y solo los visitantes enviados al que falla ven errores.
- IP móviles compartidas que chocan con un límite de peticiones: los operadores ponen a muchos usuarios detrás de una sola dirección (¿Qué es CGNAT?).
Hay tres maneras de ampliar la vista. La primera es un segundo Uptime Kuma en otro país. La segunda es el tipo de monitor Globalping, añadido en la versión 2.1.0, que prueba desde sondas alojadas por la comunidad; su campo de ubicación acepta un país, una ciudad o el nombre de un proveedor (Globalping). Globalping permite 250 pruebas por hora sin cuenta y elige entre las sondas conectadas en ese momento, así que puede que una red concreta no tenga sonda justo cuando la necesitas.
La tercera es un proxy en el monitor: la comprobación sale por una salida en el país que elijas, la misma idea en la que se basa una prueba de localización.
¿Cómo se configura un proxy en un monitor de Uptime Kuma?
Esto se refiere a las comprobaciones salientes del monitor; el panel detrás de nginx es el caso del reverse proxy visto arriba. Los ajustes de proxy solo aparecen en los monitores HTTP(s), HTTP(s) - Palabra clave y HTTP(s) - Consulta Json.
- En Ajustes, abre la sección de proxies y haz clic en Configurar Proxy.
- En Protocolo Proxy, elige HTTP o SOCKS v5 (+DNS). La lista también tiene HTTPS, SOCKS, SOCKS v5 y SOCKS v4.
- En Servidor Proxy, introduce
pr.proxynet.ioy el puerto8000para HTTP, o el puerto SOCKS5 que muestra el Generador de endpoints. - Marca El servidor Proxy tiene autenticación y rellena Usuario y Contraseña (aquí,
user:pass). Copia el nombre de usuario del Generador de endpoints del panel de Proxynet; lleva el país, la ciudad y la sesión (Autenticación de proxy). - Establecer Por Defecto asigna el proxy a los monitores nuevos, y Aplicar en todos los monitores existentes, a los actuales.
- Guarda y, después, elige Sin Proxy o el proxy en la sección Proxy de cada monitor.
Para un segundo país, haz clic en Clonar junto al proxy y cambia el país en el nombre de usuario. Así, «Pago (Türkiye)» y «Pago (Alemania)» pueden vigilar la misma dirección.
El protocolo decide dónde se resuelve el nombre del sitio. SOCKS v5 resuelve el dominio en el servidor de Uptime Kuma; SOCKS v5 (+DNS) y HTTP dejan que el proxy lo resuelva en la salida, así que el DNS también se prueba desde el país de destino (Diferencia entre SOCKS y HTTP). Para confirmar la ruta, apunta un monitor de palabra clave con el proxy a una página que muestre tu país (¿Funciona tu proxy?).
El pool de Proxies móviles tiene líneas de Turkcell, Türk Telekom y Vodafone en Türkiye. Eliges el país y la ciudad, no el operador; cada comprobación muestra cómo se comporta el sitio en una red móvil.
Si el servidor no llega a Telegram o a otro servicio de alertas, la variable de entorno NOTIFICATION_PROXY (desde la 2.0.0) envía la mayoría de las alertas a través de un proxy, aunque no el correo (variables de entorno de proxy).
¿Cuánto tráfico consume la supervisión a través de un proxy?
Los proxies residenciales y móviles se cobran por GB. Con un intervalo de 60 segundos, un monitor hace 43.200 comprobaciones en 30 días. Uptime Kuma solo descarga el HTML de la página, no las imágenes ni los scripts, pero abre una conexión nueva a través del proxy en cada comprobación, así que cada una repite el handshake TLS, el intercambio que establece el cifrado HTTPS.
Lo medimos el 25 de septiembre de 2026 enviando la petición de Uptime Kuma (sus cabeceras, sin compresión) a través de un proxy HTTP local y contando los bytes en ambos sentidos:
| Qué carga el monitor | Por comprobación | Cada 60 s, 30 días | Cada 300 s, 30 días |
|---|---|---|---|
| Página de salud pequeña, 0,5 KB de HTML | 6,8 KB | 0,29 GB | 0,06 GB |
| Página con 120 KB de HTML | 127 KB | 5,5 GB | 1,1 GB |
| La misma página, comprimida con gzip | 36,5 KB | 1,6 GB | 0,32 GB |
| La misma página, método HEAD | 7,5 KB | 0,32 GB | 0,06 GB |
Para calcular tu propia cifra, toma el tamaño del HTML sin comprimir de la página en las herramientas de desarrollo del navegador, suma 6-8 KB por la conexión y multiplícalo por las comprobaciones al mes y por el número de monitores. Para reducirlo:
- Vigila una página de salud en lugar de la página de inicio.
- Usa HEAD en Opciones HTTP > Método; se salta el cuerpo de la página, así que los monitores de palabra clave no pueden usarlo.
- Pide compresión con
{"Accept-Encoding": "gzip"}en el campo Encabezados; las comprobaciones de palabra clave siguen funcionando. - Alarga el intervalo: un monitor sin proxy cada 60 segundos y los monitores con proxy cada 2 a 5 minutos.
Con Proxies residenciales tienes una salida de conexión doméstica en el país que elijas. Una salida rotativa da a cada comprobación una IP nueva, por eso los tiempos de respuesta oscilan; con Proxies de sesión fija, la IP se mantiene durante 1-60 minutos.
Casos de uso
- La página de pago vista desde datos móviles en Türkiye: un monitor de palabra clave a través de Proxies móviles.
- Un portal de distribuidores para socios en el extranjero: un monitor por cada país de distribuidor (pruebas de localización).
- La API de tu app móvil: un monitor de consulta Json comprobado desde una red móvil (pruebas de apps).
- Una API de un socio que solo acepta IP de una lista: Uptime Kuma en un servidor con IP fija (IP estática y dinámica).
- Cambios en el contenido de una página: es otro trabajo; consulta Cómo detectar cambios en una página web y recibir alertas.
- Una comprobación puntual de «¿está caído?»: consulta This Site Can't Be Reached: qué significa y por qué aparece.
Errores habituales
- Instalar el monitor en el servidor que vigila. Cuando el servidor falla, la herramienta que debe enviar la alerta cae con él.
- Dejar Reintentos en 0. Un solo paquete perdido a las 3 de la madrugada despierta a alguien; pon 1 o 2.
- Dejar que tu propio firewall bloquee el monitor. Si tu sitio empieza a responder 403 al monitor, permite la IP del monitor (error Access Denied). Vigila solo sitios que sean tuyos o que tengas permiso para comprobar.
- SOCKS v5 simple para una prueba de ubicación. El DNS se sigue resolviendo en tu servidor.
- Activar «Ignorar errores TLS/SSL para sitios web HTTPS». También desactiva la alerta de caducidad del certificado.
- Ejecutar el contenedor sin volumen. Una actualización borra todos los monitores.
Guía de decisión
| Necesidad | Recomendación |
|---|---|
| Vigilar un sitio sin instalar nada | Un servicio alojado; Uptime Kuma si los datos deben quedarse contigo |
| Saber que la página abre con el contenido correcto | HTTP(s) - Palabra clave en la página de pago, Reintentos 1-2 |
| Ver el sitio como lo ven los usuarios móviles en Türkiye | Un monitor a través de un proxy móvil, HTTP o SOCKS v5 (+DNS) |
| Comprobar desde el país de un cliente en el extranjero | Una salida residencial en ese país; Globalping si basta una ubicación aproximada |
| Mantener bajo el tráfico del proxy | Una página de salud, HEAD o gzip, un intervalo de 2-5 minutos |
| Vigilar la API de un socio con lista de IP permitidas | Un servidor con IP fija incluido en la lista del socio |
| Abrir el panel en tu dominio con HTTPS | Un reverse proxy que pase las cabeceras de WebSocket |
Preguntas frecuentes
¿Uptime Kuma es gratis?
Sí, es software de código abierto con licencia MIT. Tus costos son el servidor en el que funciona y el tráfico de proxy, si lo usas.
¿Qué puerto usa Uptime Kuma?
El 3001 por defecto. En -p 8080:3001, el primer número es el puerto de tu servidor y el segundo, el puerto dentro del contenedor (¿Qué es el puerto 8080?).
¿Qué diferencia hay entre Uptime Kuma y UptimeRobot?
UptimeRobot es un servicio alojado sin nada que instalar; en septiembre de 2026 su plan gratuito cubría 50 monitores con un intervalo de 5 minutos. Uptime Kuma funciona en tu propio servidor sin límite de monitores, y el mantenimiento de ese servidor corre por tu cuenta.
¿Cuánto tiempo de caída permite un 99,9 % de uptime en un mes?
43 minutos y 12 segundos en un mes de 30 días, y unos 43 minutos y 50 segundos en un mes de calendario de duración media.
¿Qué es una garantía de uptime en un SLA?
Es el objetivo de disponibilidad del contrato de un proveedor. Revisa el periodo de medición, lo que queda excluido (como el mantenimiento programado) y la compensación, que muchas veces es un crédito de servicio.
¿Puede Uptime Kuma supervisar desde varias ubicaciones?
Sí, aunque la versión 2.5.5 no tiene agentes remotos: un monitor normal comprueba desde su propio servidor. Para más lugares, ejecuta copias en otros sitios, usa el tipo de monitor Globalping o da a cada monitor HTTP un proxy en otro país.
En resumen
Un porcentaje de uptime solo es tan preciso como el lugar desde el que se mide. Uptime Kuma se instala con un solo comando de Docker; da a la página de pago un monitor de palabra clave, pon Reintentos en 1 o 2 y activa la alerta de certificado. Para ver lo que ven tus clientes, ejecuta el mismo monitor a través de una salida en su país, después de calcular el tráfico. Nuestra página de servicios de proxy enumera los tipos de salida.
