Un uptime alto no es lo mismo que disponibilidad
Tu monitoreo puede reportar 99.99% y tu cliente estar furioso. La diferencia está en qué monitoreas, con qué frecuencia, y qué consideras "arriba".
"El sitio está arriba el 99.99% del tiempo" — ¿quién no vio esa frase en un pitch comercial? El número es bonito, da confort, se vuelve un badge en el pie. Pero esconde más de lo que muestra.
El uptime es una medida, no una garantía. Y como toda medida, depende de cómo definas los límites.
Qué significa "arriba" para tu monitor
La mayoría de las herramientas de monitoreo comprueba una sola cosa: un GET en la home. Si respondió 200 OK dentro del timeout, está "up". Si no respondió, está "down".
Esto pega:
- ✅ Servidor totalmente fuera
- ✅ DNS roto
- ✅ Certificado SSL expirado
- ✅ Timeout completo
Pero no pega:
- ❌ Home OK, checkout roto
- ❌ 200 OK devolviendo un HTML de error genérico ("Service Unavailable")
- ❌ Tiempo de respuesta degradado (lento pero arriba)
- ❌ API funcional, panel admin caído
- ❌ El cert SSL vence en 5 días (aún válido = "up")
Resultado: cierras el mes con 99.99% en el panel y una fila de tickets quejándose.
Los tres niveles de monitoreo
1. Disponibilidad básica (HTTP)
GET / y mirar el status code. Es el mínimo. Detecta la mayoría de los problemas catastróficos pero pierde los silenciosos.
Úsalo para: sitio institucional simple, landing page.
2. Keyword check
GET / y buscar una palabra clave en el body. Si la palabra "Bienvenido" desapareció, algo está mal — aunque el status sea 200.
Úsalo para: detectar una página de error genérica que sirve 200, defacement, un banner no programado.
3. Multi-endpoint
Monitorea por separado: home, login, API de pago, dashboard admin, webhook. Cada uno tiene su propia alerta. La página de estado lo muestra granularmente.
Úsalo para: SaaS, e-commerce, cualquier cosa donde diferentes partes pueden fallar independientemente.
Frecuencia: 1 minuto vs 5 minutos
UptimeRobot gratis comprueba cada 5 minutos. Sentinela y la mayoría de los planes de pago comprueban cada 1 minuto. La diferencia en la práctica:
- Falla a las 14:03:30, intervalo 5 min → detectada a las 14:05 → alerta ~14:06
- Falla a las 14:03:30, intervalo 1 min → detectada a las 14:04 → alerta ~14:05
Parece poco. Pero si operas un e-commerce en hora pico, 1 minuto de downtime no detectado son algunos pedidos perdidos. Multiplica por mes, se vuelve una diferencia real.
El trade-off es costo: 1/min = 5x más checks = más carga en tu servidor (pequeña) y más carga en el monitor (lo pagas en el plan).
"Estamos arriba pero estamos lentos"
La latencia degradada es el asesino silencioso. El sitio responde 200 OK, pero tardó 8 segundos. El usuario desistió antes de que llegara la respuesta. Para el monitor, todo quedó OK.
Cómo pegarlo: monitorea no solo el status, sino el tiempo de respuesta. Las métricas que importan:
- p50 (mediana): la mitad de las peticiones es más rápida que esto
- p95: el 95% de las peticiones es más rápido que esto — el peor 5%
- p99: el peor 1%
El promedio engaña. Si p50 = 100ms pero p99 = 8s, tu experiencia de usuario tiene un problema serio enmascarado por el promedio.
Ventanas de mantenimiento: reporte honesto
99.99% es honesto si lo cuentas bien. Si tiras la API todos los miércoles a las 3h para mantenimiento, eso cuenta como downtime — a menos que hayas declarado la ventana con antelación.
Un buen monitoreo permite:
- Crear una ventana de mantenimiento programada
- Suprimir alertas durante la ventana
- No contar el tiempo de la ventana contra el uptime%
- Mostrar un banner "mantenimiento programado" en la página de estado
Sin eso, o mientes en los números o pagas en falsa alarma.
La pregunta correcta no es "cuál es mi uptime"
Es: "cuando algo se rompió en los últimos 90 días, ¿me enteré antes que el cliente?"
Una métrica honesta:
- Cuántos incidentes se abrieron
- Tiempo medio de detección (de rotura → primera alerta)
- Tiempo medio de resolución (de detección → resuelto)
- En cuántos casos el cliente avisó antes que el monitor
Ese último es la prueba real. Si tuviste 3 incidentes este mes y en 2 de ellos el cliente se quejó primero, tu monitoreo no está haciendo el trabajo — independiente del número agregado.
Conclusión práctica
Antes de celebrar el 99.9%:
- Monitorea más que la home — añade checkpoints para los flujos críticos (checkout, login, API principal)
- Usa keyword check cuando la app sirve 200 en modo degradado
- Mira p95 y p99 — no solo el status — para pegar la degradación
- Declara ventanas de mantenimiento para tener un uptime honesto
- Acompaña el MTTD (tiempo de detección) — no solo el uptime
El uptime es un número fácil de divulgar. La disponibilidad real es más difícil de medir — y más importante de entregar.
Descubre en 30 segundos lo que tu dominio está mostrando.
Comprobación pasiva, sin tocar tu servidor. Sale una nota y una lista de hallazgos por gravedad — y tú decides si quieres seguirlo cada mes.