Uptime vs disponibilidad
«Uptime» y «disponibilidad» se usan indistintamente en el sector pero tienen matices importantes que afectan a cómo interpretas los datos y cómo defines los compromisos con tus clientes.
Definiciones
Uptime
En términos generales, uptime es el tiempo que un sistema ha estado operativo. Históricamente se calcula como:
Uptime = (tiempo_total - tiempo_de_caída) / tiempo_total × 100
Disponibilidad (en monitoreo sintético)
En StatusInspector, la disponibilidad se calcula a partir de los resultados de los checks:
Disponibilidad = checks_UP / checks_totales × 100
Esta métrica depende del intervalo de check: con un intervalo de 1 minuto tienes 1440 checks/día; con 5 minutos, 288. Cuanto más frecuente el check, más precisa es la medición.
¿Qué cuenta como UP?
| Estado | ¿Cuenta como UP en disponibilidad? |
|---|---|
| UP | Sí |
| DEGRADED | Sí (el servicio responde, aunque con baja calidad) |
| DOWN | No |
| UNKNOWN / Pausado | Excluido del cálculo |
El estado DEGRADED no penaliza la disponibilidad básica. Si quieres medir la «disponibilidad con calidad», deberás tratarlo por separado.
Impacto del intervalo de check
El intervalo determina la resolución de la medición. Si tu servicio se cae 2 minutos pero el intervalo es de 5 minutos, puede que ningún check capture la caída exactamente.
| Intervalo | Detección máxima | Checks/día |
|---|---|---|
| 1 minuto | ≤ 60 s | 1440 |
| 5 minutos | ≤ 5 min | 288 |
| 15 minutos | ≤ 15 min | 96 |
SLA y SLO
SLA (Service Level Agreement)
Compromiso formal con el cliente sobre el nivel mínimo de disponibilidad. Ejemplo típico:
| SLA | Downtime máximo mensual |
|---|---|
| 99 % | ~7,2 horas |
| 99,9 % | ~43,8 minutos |
| 99,95 % | ~21,9 minutos |
| 99,99 % | ~4,4 minutos |
SLO (Service Level Objective)
Objetivo interno más estricto que el SLA. Si el SLO se incumple, hay tiempo para corregir antes de que se incumpla el SLA. Ejemplo: SLA 99,9 % → SLO interno 99,95 %.
Qué mide y qué no mide un monitor sintético
Mide
- Que el endpoint responde desde las regiones de los probes.
- El código HTTP y el tiempo de respuesta.
- El contenido de la respuesta (assertions).
- La disponibilidad del certificado SSL.
No mide
- La experiencia de usuarios en regiones no cubiertas por probes.
- La disponibilidad de componentes internos no expuestos (base de datos, cola de mensajes).
- Degradaciones sutiles que no afectan a la respuesta HTTP pero sí a la experiencia del usuario.
Para medir esos aspectos complementa con Heartbeat (procesos internos), monitoreo de infraestructura (métricas de servidor) y RUM (Real User Monitoring).
Buenas prácticas
- Usa intervalos de 1 minuto para servicios críticos donde los SLA son ajustados.
- Para el cálculo del SLA, excluye las ventanas de mantenimiento planificado negociadas con el cliente.
- Distingue la disponibilidad del servicio (un endpoint específico) de la disponibilidad de la plataforma (todos tus servicios).
- Comunica claramente el método de cálculo a tus clientes para evitar disputas sobre los números.