Monitorización de SLA: cómo medir e informar un uptime del 99,9%

«Garantizamos un uptime del 99,9 %.» Es una promesa que hacen la mayoría de las empresas SaaS. ¿Pero cuántas pueden demostrarlo? La monitorización de SLA convierte esa promesa de copy de marketing en un compromiso medible e informable.

Entender los SLA de uptime

¿Qué significa realmente «99,9 % de uptime»?

Los números suenan impresionantes, pero la diferencia entre cada «nueve» es importante:

| SLA | Tiempo de inactividad anual | Tiempo de inactividad mensual |
|-----|-----------------------------|--------------------------------|
| 99 % | 3 días, 15 horas | 7 horas, 18 min |
| 99,5 % | 1 día, 19 horas | 3 horas, 39 min |
| 99,9 % | 8 horas, 46 min | 43 min, 50 s |
| 99,95 % | 4 horas, 23 min | 21 min, 55 s |
| 99,99 % | 52 min, 36 s | 4 min, 23 s |

Con un 99,9 %, tienes menos de 44 minutos de inactividad permitida al mes. Eso incluye mantenimiento planificado, caídas sorpresa y degradaciones parciales. Es un margen ajustado.

SLA frente a SLO frente a SLI

Estos términos suelen confundirse:

• SLI (Service Level Indicator) — La métrica que mides: porcentaje de uptime, tiempo de respuesta, tasa de error.
• SLO (Service Level Objective) — Tu objetivo interno: «La API debería estar disponible el 99,95 % del tiempo.»
• SLA (Service Level Agreement) — El compromiso contractual con consecuencias económicas: «Si el uptime cae por debajo del 99,9 %, los clientes reciben créditos de servicio.»

Tu SLO debería ser más estricto que tu SLA. Si tu SLA promete 99,9 %, tu objetivo interno debería ser 99,95 % o superior. Así tienes margen antes de que las infracciones del SLA disparen penalizaciones financieras.

Cómo medir el uptime

La fórmula básica

```
Uptime % = ((Minutos totales − Minutos de inactividad) / Minutos totales) × 100
```

Para un mes de 30 días (43 200 minutos):

• 20 minutos de inactividad = 99,954 % de uptime
• 44 minutos de inactividad = 99,898 % de uptime (incumplimiento del SLA al 99,9 %)
• 120 minutos de inactividad = 99,722 % de uptime

¿Qué cuenta como inactividad?

Aquí entra el matiz. Tu SLA debería definir con claridad:

Suele contar como inactividad:

• Indisponibilidad total del servicio (errores 5xx, timeouts)
• Degradación grave del rendimiento (tiempos de respuesta > 10× lo normal)
• Fallos de autenticación que impiden el acceso
• Pérdida o corrupción de datos

Suele excluirse:

• Ventanas de mantenimiento programado (con aviso previo)
• Fuerza mayor (catástrofes naturales, grandes caídas de internet)
• Problemas causados por el cliente (llamadas API mal configuradas)
• Dependencias de terceros fuera de tu control

Documenta estas definiciones en tu SLA. La ambigüedad no beneficia a nadie.

Monitoring para el cumplimiento del SLA

Para medir el uptime con precisión con fines de SLA:

Comprueba con frecuencia: intervalos de 1 minuto o 30 segundos te dan mediciones de inactividad precisas. Un intervalo de 5 minutos implica que tus mediciones solo son exactas con un margen de ±5 minutos — es relevante cuando tu presupuesto mensual son 44 minutos.

Monitoriza desde varias ubicaciones: una caída que solo afecta a usuarios europeos sigue siendo una caída. El monitoring multirregión te ayuda a detectar problemas localizados.

Sigue el uptime por componente: tu SLA puede cubrir el servicio global, pero el seguimiento por componente ayuda a identificar eslabones débiles: «Nuestra API tuvo un uptime del 99,99 %, pero el sistema de entrega de webhooks solo alcanzó el 99,7 %.»

Excluye ventanas de mantenimiento: si tu SLA permite mantenimiento programado, asegúrate de que tu herramienta de monitoring admita ventanas de mantenimiento para que esos periodos no resten del uptime.

Cómo construir un informe de SLA

Métricas esenciales

Todo informe de SLA debería incluir:

1. Porcentaje global de uptime — El número principal.
2. Número de Incidents — Cuántas veces el servicio estuvo caído.
3. Inactividad total — Minutos u horas agregadas de indisponibilidad.
4. Mean Time to Detect (MTTD) — Cuánto tardaste en detectar cada problema.
5. Mean Time to Recovery (MTTR) — Cuánto tardaste en resolver cada problema.
6. Incident más largo — Tu peor caída en el periodo informado.
7. Comparación de tendencias — Cómo se compara este periodo con los anteriores.

Periodicidad de los informes

• Mensual: estándar en la mayoría de acuerdos de SLA. Incluye las métricas anteriores más una lista de Incidents con marcas de tiempo y descripciones.
• Trimestral: formato de revisión de negocio. Incluye tendencias, iniciativas de mejora e inversiones en infraestructura.
• Anual: visión estratégica para dirección y clientes enterprise. Incluye comparaciones año a año y hoja de ruta de fiabilidad.

Hacer los informes accionables

Un informe que solo dice «99,94 % de uptime» aporta poco. Complétalo con:

• Desglose de Incidents: qué pasó, cómo se detectó, cómo se solucionó y qué haréis para evitar que se repita.
• Seguimiento del error budget: si tu SLA es 99,9 % y has consumido 30 de los 44 minutos de inactividad permitidos este mes, el equipo sabe que debe ir con cuidado con despliegues arriesgados.
• Análisis de tendencias: ¿mejora o empeora el uptime? ¿Los Incidents son más o menos frecuentes?

Estrategias para mantener un uptime alto

Gestión del error budget

El concepto de «error budget» del marco SRE de Google es muy útil. Tu error budget es la diferencia entre el 100 % y tu objetivo SLO.

Para un SLO del 99,9 % en 30 días, tu error budget son 43 minutos.

Cuando vas dentro del presupuesto, puedes ir rápido: desplegar con frecuencia, experimentar y asumir riesgos calculados. Cuando te queda poco margen, reduce el ritmo: congela despliegues no críticos, aumenta las pruebas y céntrate en la fiabilidad.

Invertir donde más importa

No todas las mejoras de uptime son iguales. Prioriza:

1. Eliminar puntos únicos de fallo — La base de datos sin réplica, el servidor sin failover, el proveedor DNS sin respaldo.
2. Reducir el riesgo de despliegue — Despliegues blue-green, canary y rollbacks automáticos evitan caídas por despliegues.
3. Mejorar la velocidad de detección — Detectar antes acorta las caídas. La diferencia entre 15 segundos y 5 minutos puede ser cumplir el SLA o incumplirlo.
4. Automatizar la recuperación — Sistemas auto curativos que reinician procesos, redirigen tráfico y escalan recursos automáticamente.

Usar un Status Page para transparencia

Un Status Page público no sube el uptime por sí solo, pero cambia cómo los clientes perciben tu fiabilidad:

• Comunicar de forma proactiva durante los Incidents genera confianza
• El historial de Incidents demuestra tu trayectoria
• Las notificaciones a suscriptores mantienen informados a los clientes
• La transparencia reduce el volumen de tickets de soporte

Conclusión

La monitorización de SLA no es solo cumplimiento contractual: es construir una cultura de fiabilidad. Cuando mides el uptime con rigor, lo informas con transparencia y gestionas el error budget con intención, creas un bucle de mejora continua.

Empieza definiendo objetivos de uptime claros, configurando un monitoring preciso e informando con honestidad. Los números vendrán después.

Mide tu SLA con precisión. Empieza a monitorizar gratis — informes detallados de uptime, seguimiento de Incidents y Status Pages incluidos.