Un SLI (service level indicator, indicador de nivel de servicio) es una medición de cómo se comporta tu servicio, como el porcentaje de peticiones correctas. Un SLO (service level objective, objetivo de nivel de servicio) es el objetivo interno para esa medición, como que el 99,9 % de las comprobaciones salgan bien a lo largo de 30 días. Un SLA (service level agreement, acuerdo de nivel de servicio) es la promesa que haces a los clientes, normalmente con un objetivo más bajo que el SLO y una consecuencia, como un crédito de servicio, si no lo cumples. El indicador es lo que mides, el objetivo es a lo que aspiras y el acuerdo es lo que firmas.
Esta guía explica cada término con ejemplos, muestra lo que significan los porcentajes de disponibilidad en minutos y te guía para elegir indicadores para una web o una API, decidir qué cuenta como tiempo de inactividad y redactar un SLA que los clientes puedan entender.
Los tres términos, en palabras sencillas
SLI: la medición
Un indicador de nivel de servicio es una cifra que puedes calcular a partir de datos reales. Casi siempre es una proporción: eventos buenos divididos entre todos los eventos. Para una web, podría ser el porcentaje de comprobaciones de disponibilidad que devolvieron la respuesta esperada. Para una API, el porcentaje de peticiones que respondieron con un estado distinto de 5xx en menos de 500 milisegundos. Un SLI no lleva ningún objetivo asociado. Simplemente dice lo que ha pasado.
SLO: el objetivo
Un objetivo de nivel de servicio añade una meta y una ventana de tiempo a un SLI. «El 99,9 % de las comprobaciones al checkout salen bien, medido en una ventana móvil de 30 días» es un SLO. Es una herramienta interna. Le dice al equipo cuándo la fiabilidad es suficiente para seguir lanzando funcionalidades y cuándo toca frenar y arreglar cosas.
SLA: el contrato
Un acuerdo de nivel de servicio es la promesa externa, recogida en un contrato o en las condiciones del servicio. Indica el servicio, el objetivo, cómo se mide, qué queda excluido y qué recibe el cliente si no lo cumples. No todos los servicios necesitan un SLA, pero todo SLA necesita un SLO detrás; si no, no tienes ningún aviso previo de que estás a punto de incumplirlo.
Cómo encajan SLI, SLO y SLA
Piensa en ellos como capas. El SLI es la señal en bruto. El SLO es una línea interna más estricta trazada sobre esa señal. El SLA es una línea externa más holgada trazada sobre la misma señal. Una configuración habitual para un producto SaaS es así (valores de ejemplo):
SLI: porcentaje de comprobaciones cada minuto a app.lumenanalytics.io que devuelven el estado 200 y contienen el título del panel.
SLO: 99,95 % por mes natural.
SLA: 99,9 % por mes natural, con un crédito de servicio si no se cumple.
La diferencia entre el 99,95 % y el 99,9 % es el margen de seguridad. Si el equipo ve que el SLO se resiente en la segunda semana, todavía tiene tiempo de actuar antes de que la promesa contractual esté en peligro.
Porcentajes de disponibilidad en minutos
Sobre el papel, los objetivos de disponibilidad parecen muy próximos, pero cada nueve adicional divide entre diez el tiempo de inactividad permitido. La tabla siguiente usa un mes medio (un año de 365,25 días dividido entre 12), igual que la calculadora de disponibilidad; un mes de 30 días permite algo menos.
Objetivo de disponibilidadInactividad permitida al mesInactividad permitida al año99 %7 h 18 min 18 s3 días 15 h 39 min 36 s99,5 %3 h 39 min 9 s1 día 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
De ahí se derivan dos consecuencias prácticas. Primero, tu monitorización tiene que poder ver el tiempo de inactividad que prometes. Con comprobaciones cada cinco minutos no puedes medir con honestidad un objetivo mensual del 99,99 %, porque una sola caída no detectada podría consumir todo el presupuesto. Segundo, cualquier objetivo por encima del 99,9 % apenas deja margen para una respuesta manual. Con el 99,99 %, un solo incidente nocturno que se resuelva despacio acaba con el mes.
Presupuestos de error: convertir el SLO en decisiones
Un presupuesto de error es la cantidad de fallo que permite tu SLO. Con un SLO mensual del 99,9 %, el presupuesto es el 0,1 % del mes, unos 43 minutos y 49 segundos en un mes medio (43 minutos y 12 segundos en uno de 30 días). Cada incidente consume una parte.
El presupuesto convierte la fiabilidad en una decisión compartida en lugar de una discusión. Una política sencilla que usan muchos equipos:
Queda más de la mitad del presupuesto: se despliega con normalidad.
Queda menos de la mitad: se revisan los despliegues arriesgados y los cambios en la base de datos pasan por una segunda persona.
Presupuesto agotado: se pausan los lanzamientos de funcionalidades de ese servicio y se trabaja en las causas de los últimos incidentes hasta que se reinicie la ventana.
Un ejemplo: harborlabs.dev tiene un SLO mensual del 99,9 % para su API pública. El día 9, un despliegue defectuoso provoca 18 minutos de errores. El día 20, un problema con un certificado provoca 9 más. Son 27 de 43 minutos consumidos, con diez días por delante. El equipo aplaza la siguiente migración de esquema hasta el mes nuevo, porque un incidente más del mismo tamaño incumpliría el objetivo.
Cómo elegir SLI para una web o una API
Los buenos SLI describen lo que viven los usuarios, no lo que sienten tus servidores. Una CPU al 90 % no es un SLI. Un checkout que falla, sí. Empieza con dos o tres indicadores por servicio:
Disponibilidad: el porcentaje de comprobaciones o peticiones que salen bien. Para una web, «salir bien» debería significar el código de estado correcto y el contenido correcto, no solo una respuesta.
Latencia: el porcentaje de peticiones que responden por debajo de un umbral, por ejemplo el 95 % en menos de 800 ms. Un porcentaje es más fácil de interpretar que una media, que oculta los valores atípicos lentos.
Corrección: en las API, el porcentaje de respuestas que contienen los campos esperados. Un 200 con el cuerpo vacío no es un éxito.
Mide los recorridos que importan. En una tienda como northwind.shop, eso significa el checkout y las páginas de producto, no solo la página de inicio en caché. En una API, significa los endpoints con los que se integran los clientes, idealmente a través de un endpoint de health check que pruebe la base de datos y otras dependencias. Un monitor de API que valida el cuerpo de la respuesta convierte ese endpoint en un SLI fiable.
Qué cuenta para la disponibilidad
La mayoría de las disputas sobre SLA no tratan de la cifra. Tratan de qué cuenta. Decide estos puntos antes de publicar un objetivo:
Mantenimiento planificado. Muchos SLA excluyen el mantenimiento programado anunciado con antelación, por ejemplo con 72 horas de aviso y un máximo de cuatro horas al mes. Si lo excluyes, indica cómo se anuncia y fija un límite, o el «mantenimiento» se convertirá en un resquicio.
Caídas parciales. ¿Está caído el servicio si el inicio de sesión funciona pero el checkout falla? Define qué componentes cubre y si la caída de uno cuenta como inactividad del conjunto.
Rendimiento degradado. Decide si las respuestas más lentas que un umbral cuentan como fallos. Si una página tarda 30 segundos, los usuarios la consideran caída.
Causas fuera de tu control. Los problemas de red del cliente, el uso indebido y la fuerza mayor suelen excluirse. Tu propio proveedor de hosting normalmente no; los clientes te compraron el servicio a ti.
Duración mínima. Algunos SLA solo cuentan las caídas de más de un minuto o las confirmadas por más de una comprobación, lo que coincide con cómo confirma los fallos la monitorización.
Internamente, suele ser buena idea contar el mantenimiento planificado en tu SLO aunque el SLA lo excluya. Los usuarios tampoco podían acceder al servicio, y el SLO debe reflejar su experiencia.
Cómo redactar un SLA para clientes
Un buen SLA es breve y concreto. Debe responder a seis preguntas: qué servicio, qué objetivo, cómo se mide, en qué periodo, con qué exclusiones y qué pasa si no se cumple. Aquí tienes una cláusula de ejemplo que puedes adaptar:
Servicio: la aplicación web de Lumen Analytics en app.lumenanalytics.io
y la API pública en api.lumenanalytics.io.
Objetivo: 99,9 % de disponibilidad mensual.
Medición: la disponibilidad se mide con comprobaciones externas cada minuto.
Un minuto cuenta como no disponible cuando el servicio devuelve un error (5xx)
o no responde, confirmado por una segunda comprobación.
Exclusiones: mantenimiento programado anunciado con al menos 72 horas de
antelación en nuestra página de estado (máx. 4 horas al mes); problemas
causados por la red o los sistemas propios del cliente.
Créditos: por debajo del 99,9 %: 10 % de la cuota mensual.
por debajo del 99,0 %: 25 % de la cuota mensual.
Los clientes solicitan los créditos en los 30 días siguientes al cierre del mes.
Fija el SLA por debajo de lo que realmente consigues. Si tu historial de monitorización muestra un 99,97 % durante el último año, prometer un 99,9 % es realista. Prometer un 99,99 % porque suena mejor convierte cada incidente en un problema contractual.
Mantén los créditos proporcionados y el proceso de reclamación sencillo. Los clientes rara vez quieren el dinero. Quieren ver que te tomas la promesa en serio y que mides con honestidad.
Medir con monitorización externa
Tus propios logs no pueden medir una caída en la que tu servidor nunca recibió la petición. Los fallos de DNS, los certificados caducados, los problemas de red y un balanceador de carga caído dejan las métricas internas en silencio. Por eso la medición del SLA debe hacerse desde fuera, igual que llegan a ti los clientes. Si la idea es nueva para ti, empieza por qué es la monitorización de disponibilidad y cómo funciona.
Una configuración sólida para los informes de SLA:
Comprueba cada minuto. El intervalo marca la resolución de tu medición.
Confirma cada fallo con una segunda comprobación. Así un simple parpadeo de la red no entra en tus cifras de inactividad.
Valida el contenido. Busca una palabra o un campo que solo aparezca cuando el servicio funciona.
Conserva el historial. Necesitas la hora de inicio y fin de cada incidente de todos los meses sobre los que informas.
Publícalo. Una página de estado con historial de disponibilidad permite a los clientes ver las mismas cifras que tú.
Uptimecheck cubre todo esto con monitorización de disponibilidad hasta cada minuto desde Estocolmo, Londres y Nueva York, informes de SLA por monitor para este mes o el anterior o para los últimos 7, 30 o 90 días frente a tu objetivo, exportación a CSV para la declaración mensual de SLA e informes semanales y mensuales por email. Una página de estado conectada a los mismos monitores muestra a los clientes el historial de disponibilidad que respalda tu promesa.
La disponibilidad es solo una cara de la fiabilidad. La rapidez con la que detectas y resuelves los incidentes decide cuánto presupuesto consume cada uno; lee MTTR, MTTA y MTBF explicados para la parte de la respuesta.
Checklist: cómo fijar SLI, SLO y un SLA
Enumera los recorridos de usuario que importan: inicio de sesión, checkout, la API principal.
Define un SLI de disponibilidad y, cuando importe, uno de latencia por recorrido.
Mide durante uno o dos meses antes de elegir objetivos.
Fija el SLO ligeramente por debajo de lo que consigues hoy y acordad una política de presupuesto de error.
Fija el SLA por debajo del SLO, con exclusiones claras y créditos proporcionados.
Mide desde fuera cada minuto y revisa las cifras cada mes.
Mide la disponibilidad que prometes desde donde están tus clientes. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.