SLA: guía completa de acuerdos de nivel de servicio 2026

El 68% de los contratos de TI en España no definen SLOs medibles — una auditoría interna realizada por abemon sobre contratos de managed services activos en 2026. Esta cifra no es sorprendente para quien trabaja en operaciones de TI: abundan los documentos que prometen “alta disponibilidad”, “respuesta rápida” y “soporte prioritario” sin un solo número detrás. El resultado es predecible: cuando ocurre una incidencia, cada parte del contrato lee las cosas de forma distinta, los SLAs se convierten en papel mojado y la relación proveedor-cliente se deteriora.

Un SLA bien construido no es un requisito burocrático. Es un mecanismo de gobernanza que alinea incentivos, define responsabilidades y permite medir el valor entregado. En abemon gestionamos SLAs para más de 40 organizaciones desde nuestro servicio de managed services y reducción de costes operativos. Esta guía recoge lo que funciona en producción.

¿Qué es un SLA?

Un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) es un contrato formal, habitualmente entre un proveedor de servicios y un cliente, que establece las expectativas de rendimiento del servicio, los métodos de medición y las consecuencias ante el incumplimiento. A diferencia de un contrato de alcance técnico, el SLA se centra en el comportamiento del servicio desde la perspectiva del usuario o del negocio.

Cuatro términos se confunden con frecuencia en este contexto:

Concepto	Significado	Ejemplo	¿Contractual?
SLI (Service Level Indicator)	Métrica cruda medida en producción	% de peticiones con latencia < 200 ms	No
SLO (Service Level Objective)	Objetivo interno sobre un SLI, con ventana temporal	SLI ≥ 99,5% en ventana deslizante de 30 días	No (objetivo interno)
SLA (Service Level Agreement)	Acuerdo contractual con consecuencias económicas	SLO ≥ 99,9% medido mensualmente; crédito del 10% si no se cumple	Sí
OLA (Operational Level Agreement)	Equivalente interno entre equipos de la misma organización	El equipo de plataforma garantiza al equipo de desarrollo un pipeline de CI/CD disponible al 99,5%	Interno
UC (Underpinning Contract)	Contrato con un proveedor externo que sustenta el SLA	AWS garantiza el 99,99% en EC2 con arquitectura multi-AZ	Sí (B2B)

La jerarquía operativa es: los SLIs alimentan los SLOs, los SLOs se convierten en SLAs frente al cliente, y los UCs con proveedores externos deben cubrir los SLAs que se prometen. Si el UC con un proveedor cloud garantiza solo el 99.9% y el SLA que se ofrece al cliente es del 99.95%, existe un riesgo estructural.

Componentes obligatorios de un SLA

Un SLA sin alguno de estos elementos es incompleto y potencialmente inexigible:

• Alcance del servicio: qué está cubierto (y qué no). Sin una definición explícita del perímetro, cualquier incidencia puede ser objeto de disputa.
• Métricas y SLOs: los indicadores concretos (disponibilidad, tiempo de respuesta, tiempo de resolución) con sus valores objetivo expresados como porcentajes o intervalos de tiempo.
• Ventana de medición: si la disponibilidad se mide en el mes natural, en ventanas de 30 días deslizantes, o en períodos distintos. Esta cláusula es la que más frecuentemente falta y la que más conflictos genera.
• Exclusiones: mantenimiento programado anunciado con antelación suficiente (habitualmente 72 horas), incidentes causados por el cliente, eventos de fuerza mayor, ataques de denegación de servicio fuera del alcance del proveedor.
• Penalizaciones y créditos: tabla de créditos escalonada con los umbrales de incumplimiento y el máximo aplicable. Debe especificarse si los créditos se aplican automáticamente o requieren reclamación.
• Procedimiento de escalado: tiempos de respuesta por severidad, contactos designados, canales de comunicación durante una incidencia.
• Proceso de revisión: cadencia formal para revisar el cumplimiento del SLA, quién participa y con qué datos.
• Proceso de reclamación: plazo para presentar reclamaciones, documentación requerida y plazo de resolución por parte del proveedor.

Tipos de SLA

Existen tres arquitecturas principales de SLA, que responden a necesidades distintas:

Customer SLA (SLA de cliente) Es el acuerdo entre un proveedor y un cliente final. Define las expectativas del servicio desde la perspectiva del negocio. Es el tipo más común en contratos de software, managed services y servicios cloud. La ventaja es su claridad; la desventaja, que puede requerir múltiples SLAs si distintos servicios tienen distintos niveles de criticidad.

Internal SLA (SLA interno u OLA) Es el equivalente a un Customer SLA, pero entre departamentos o equipos dentro de la misma organización. Por ejemplo, el equipo de infraestructura puede tener un OLA con el equipo de desarrollo que garantice tiempos de provisión de entornos. Son fundamentales en organizaciones que han adoptado modelos de plataforma interna (platform engineering), donde un equipo central presta servicios a otros equipos.

Multi-level SLA Estructura jerárquica que descompone el SLA en varios niveles: corporativo (aplica a todos los clientes), cliente (específico por organización) y servicio (específico por funcionalidad). Es el modelo más sofisticado, recomendado para proveedores de servicios con carteras amplias de clientes o de servicios. Permite gestionar compromisos diferenciados sin multiplicar documentos.

En la práctica, la elección del tipo depende de la complejidad de la relación de servicio. Un proveedor de managed services con 10 clientes y 3 niveles de soporte se beneficia de un Multi-level SLA. Una empresa con un único proveedor de hosting puede gestionar con un Customer SLA sencillo.

Métricas SLA que realmente importan (con fórmulas)

Disponibilidad (Uptime)

La métrica más utilizada en SLAs de infraestructura y plataformas digitales.

Fórmula:

Disponibilidad (%) = (Tiempo total − Tiempo de indisponibilidad) / Tiempo total × 100

La tabla siguiente convierte porcentajes en tiempo real de indisponibilidad permitido:

SLA Uptime	Indisponibilidad anual	Indisponibilidad mensual	Indisponibilidad semanal
99,0%	3 días 15 h 36 min	7 h 18 min	1 h 40 min
99,5%	1 día 19 h 48 min	3 h 39 min	50 min
99,9%	8 h 45 min	43 min	10 min
99,95%	4 h 22 min	21 min	5 min
99,99%	52 min	4,3 min	1 min
99,999%	5,25 min	25,9 seg	6 seg

La diferencia de ingeniería (y de coste) entre 99.9% y 99.99% es significativa: requiere arquitecturas activo-activo con failover automático, geo-redundancia y procedimientos de recuperación probados. No es una cuestión de presupuesto adicional marginal.

MTTR (Mean Time To Recovery)

Tiempo medio de recuperación tras una incidencia.

MTTR = Tiempo total de recuperación / Número de incidencias

Un MTTR bajo indica que los procesos de detección, diagnóstico y restauración son eficientes. Un MTTR alto suele revelar ausencia de runbooks, falta de observabilidad o dependencias no documentadas.

MTBF (Mean Time Between Failures)

Tiempo medio entre fallos. Mide la fiabilidad del sistema.

MTBF = Tiempo total de operación / Número de fallos

Un MTBF alto indica un sistema estable. La combinación de MTBF alto y MTTR bajo define un sistema con alta disponibilidad práctica.

Tiempo de respuesta inicial

Tiempo transcurrido desde que se registra una incidencia hasta que el proveedor confirma su recepción y asigna un técnico. Se mide por severidad (P1, P2, P3, P4).

Tiempo de resolución

Tiempo total desde el registro de la incidencia hasta que el servicio está completamente restaurado. Diferente del tiempo de respuesta; es el más relevante para el negocio.

Throughput y capacidad

Para servicios de procesamiento de datos o APIs, el SLA puede incluir compromisos de throughput mínimo (transacciones por segundo, mensajes procesados por minuto) y de capacidad máxima garantizada bajo carga.

Cómo redactar los SLOs (con ejemplos)

La diferencia entre un SLO útil y uno inútil es la precisión. Un SLO debe responder a: ¿qué se mide? ¿cómo se mide? ¿en qué ventana temporal? ¿con qué exclusiones?

SLO malo:

“El servicio tendrá alta disponibilidad.”

No define qué es disponible, quién lo mide, en qué ventana ni qué ocurre cuando no se cumple.

SLO mediocre:

“Disponibilidad del 99,9%.”

Falta la ventana de medición, el método de cálculo y las exclusiones. Dos partes pueden leer este SLO de forma completamente distinta.

SLO correcto:

“El porcentaje de minutos en que la API de pagos devuelve respuestas HTTP 2xx o 3xx, medido sobre ventanas deslizantes de 30 días naturales, será igual o superior al 99,9%. Se excluyen los períodos de mantenimiento programado comunicados con un mínimo de 72 horas de antelación por correo electrónico a los contactos técnicos designados. La medición se realizará desde tres sondas externas ubicadas en Madrid, Frankfurt y Dublín.”

Este SLO especifica: el servicio (API de pagos), la señal (respuestas 2xx/3xx), la ventana (30 días deslizantes), el umbral (99,9%), las exclusiones (mantenimiento programado) y el método de medición (sondas externas geolocalizadas).

SLO para tiempo de respuesta:

“El percentil 95 de la latencia de respuesta de la API de búsqueda, medido sobre períodos de 5 minutos, será inferior a 800 ms durante las horas pico (08:00–20:00 CET), con exclusión de los días declarados de mantenimiento. El percentil 99 no superará los 2.000 ms.”

El uso de percentiles (p95, p99) en lugar de promedios es fundamental: los promedios ocultan colas largas que impactan a una minoría significativa de usuarios.

SLAs para servicios cloud gestionados

Los principales proveedores cloud publican SLAs para sus servicios individuales. Conviene entender qué cubren y qué no.

AWS: Amazon EC2 garantiza el 99,99% de disponibilidad mensual para instancias en múltiples zonas de disponibilidad. Amazon RDS Multi-AZ ofrece el 99,95%. Sin embargo, estos SLAs cubren la disponibilidad de la infraestructura, no la de la aplicación completa del cliente. El crédito máximo es del 30% de la factura mensual del servicio afectado.

Microsoft Azure: Azure Virtual Machines con Availability Zones garantizan el 99,99%. Azure SQL Database (Business Critical) ofrece el 99,995%. El modelo de créditos de Azure es similar al de AWS: escalonado según el nivel de indisponibilidad.

Google Cloud Platform: Compute Engine ofrece el 99,99% con instancias en múltiples zonas. Cloud SQL en configuración HA garantiza el 99,95%.

Lo que estos SLAs no cubren:

• La disponibilidad de la aplicación del cliente desplegada sobre la infraestructura.
• Las dependencias de red fuera de la red del proveedor.
• Los errores introducidos por el cliente en su configuración.
• Los servicios de terceros integrados en la arquitectura.

Para servicios gestionados que construyen sobre cloud, el SLA hacia el cliente debe considerar la suma de riesgos de cada capa. Una arquitectura bien documentada de dependencias es el punto de partida para comprometerse con un SLA realista. Véase también la guía sobre observabilidad en microservicios para entender cómo instrumentar estas capas.

Penalizaciones y créditos de servicio

Las penalizaciones en los SLAs de TI operan habitualmente como créditos de servicio, no como pagos directos. El modelo más extendido es:

Tabla de créditos escalonada (ejemplo estándar):

Disponibilidad mensual	Crédito sobre factura mensual
≥ 99,9%	0% (SLA cumplido)
99,0% – 99,9%	10%
95,0% – 99,0%	25%
< 95,0%	30% (máximo contractual)

Cálculo del crédito:

Crédito = Factura mensual × Porcentaje de crédito aplicable

Si la factura mensual es de 5.000 € y la disponibilidad fue del 98,5% (en el tramo del 25%), el crédito sería de 1.250 €, aplicado como descuento en la factura siguiente.

Consideraciones importantes:

• El límite máximo de crédito suele situarse entre el 10% y el 30% de la factura mensual. Valores superiores son inusuales y deben analizarse en el contexto contractual completo.
• El crédito no cubre los daños directos o indirectos sufridos por el cliente como consecuencia de la indisponibilidad. Si se necesita cobertura de daños, debe pactarse explícitamente o gestionarse mediante seguros de responsabilidad civil tecnológica.
• Los procedimientos de reclamación suelen requerir notificación escrita en un plazo de 30 días desde el incidente. Los créditos no reclamados dentro del plazo habitualmente no se aplican.
• En entornos de compliance normativo (ENS, DORA, ISO 27001), las penalizaciones pueden extenderse más allá de los créditos económicos para incluir auditorías obligatorias o reporting regulatorio.

Procesos SLA: monitoreo, reporting y gobernanza

Un SLA sin proceso operativo detrás es un documento sin valor. La operativización de un SLA requiere cuatro pilares:

1. Instrumentación y monitoreo continuo

Las métricas del SLA deben medirse de forma continua, automatizada y desde perspectivas externas (no solo desde la infraestructura interna). Las herramientas recomendadas:

• Datadog: observabilidad integral con SLO tracking nativo. Permite definir SLOs sobre métricas o monitores y calcular el error budget restante en tiempo real.
• Grafana + Alertmanager: opción de código abierto flexible para organizaciones con capacidad de operación propia.
• Better Stack: monitorización de uptime externa con alertas multicanal y gestión de incidencias integrada.
• Pingdom / UptimeRobot: monitorización de disponibilidad HTTP/TCP desde múltiples ubicaciones geográficas.

2. Error budget management

El error budget es la diferencia entre el 100% y el SLO comprometido. Para un SLO del 99,9%, el error budget mensual es de 43,2 minutos. La gestión del error budget permite tomar decisiones informadas: si el equipo ha consumido el 80% del budget en la segunda semana del mes, debe priorizar estabilidad sobre nuevas funcionalidades.

3. Reporting y cadencia de revisión

Un modelo de reporting efectivo incluye:

• Dashboard en tiempo real: visible para todos los equipos involucrados. El verde/rojo de los SLOs no debe ser información exclusiva del equipo de operaciones.
• Informe mensual: cumplimiento por servicio, incidencias relevantes, análisis de causa raíz (RCA) de los incumplimientos.
• Revisión trimestral: análisis de tendencias, propuesta de ajuste de SLOs si los objetivos actuales ya no son representativos del valor entregado.

4. RACI del proceso SLA

Actividad	Responsable	Aprobador	Consultado	Informado
Medición de SLIs	Equipo de plataforma	—	—	—
Cálculo de SLOs	Equipo de operaciones	Service Manager	—	—
Notificación de incumplimiento	Service Manager	—	Dirección	Cliente
Gestión de reclamaciones	Account Manager	Director de Servicio	Legal	Cliente
Revisión y actualización de SLA	Service Manager	Director de Servicio	Cliente	—

Errores frecuentes en SLAs

1. Ausencia de ventana de medición

El error más común y el más costoso. “99,9% de disponibilidad” sin especificar si se mide en el mes natural, en ventanas de 30 días deslizantes o en ventanas de 24 horas es una cláusula que no puede auditarse de forma objetiva.

2. Medir la disponibilidad desde dentro de la infraestructura

Un servicio puede aparecer como disponible en los monitores internos mientras los usuarios externos no pueden acceder a él por un problema de red o de DNS. Los SLAs deben medirse desde sondas externas que simulen el acceso del usuario final.

3. Promedios en lugar de percentiles

Un tiempo de respuesta promedio de 300 ms puede coexistir con un percentil 99 de 5.000 ms. Los promedios ocultan los problemas de colas que afectan a una fracción significativa de los usuarios. Los SLOs de latencia deben expresarse en p95 o p99.

4. Excluir el mantenimiento programado sin límite

Es razonable excluir el mantenimiento programado del cálculo de disponibilidad, pero sin un límite máximo (por ejemplo, no más de 4 horas de mantenimiento al mes), el proveedor puede declarar mantenimiento programado para cubrir incidencias reales.

5. SLA desconectado de la arquitectura real

Comprometerse con un SLA de 99,99% sobre una arquitectura con un único punto de fallo es un error estructural. Antes de firmar un SLA, debe validarse que la arquitectura técnica es capaz de sostener el objetivo comprometido.

6. No definir severidades de incidencia

Sin una clasificación formal de severidades (P1: crítico, impacta a todos los usuarios; P2: degradación parcial; P3: funcionalidad secundaria afectada; P4: mejora/consulta), los tiempos de respuesta pactados no pueden aplicarse de forma coherente.

7. Olvidar las dependencias de terceros

Si el servicio depende de una pasarela de pagos, una API externa o un proveedor de identidad, el SLA debe explicitar qué ocurre cuando la indisponibilidad se origina en esas dependencias. La opacidad en este punto genera conflictos recurrentes.

8. SLA estático en un servicio que evoluciona

Un SLA firmado en el momento del lanzamiento de un servicio puede ser irrelevante 18 meses después si el servicio ha escalado, ha incorporado nuevas funcionalidades o ha cambiado su arquitectura. Sin una cláusula de revisión periódica, el SLA pierde vigencia operativa sin perder vigencia contractual.

Plantilla mínima de SLA

La siguiente lista de verificación recoge los elementos que todo SLA debería cubrir antes de ser firmado:

Identificación y alcance

• Partes del acuerdo (proveedor, cliente, contactos designados)
• Descripción del servicio cubierto y perímetro exacto
• Fecha de entrada en vigor y duración
• Proceso de modificación y notificación de cambios

Métricas y SLOs

• Lista de SLIs medidos (disponibilidad, latencia, throughput, etc.)
• Valor objetivo (SLO) para cada SLI
• Ventana de medición definida explícitamente
• Método de medición (herramienta, ubicación de las sondas)
• Exclusiones al cálculo de disponibilidad

Soporte e incidencias

• Clasificación de severidades con criterios objetivos
• Tiempo de respuesta inicial por severidad
• Tiempo de resolución objetivo por severidad
• Canales de comunicación durante incidencias
• Escalado: contactos y umbrales temporales

Penalizaciones y reclamaciones

• Tabla de créditos por nivel de incumplimiento
• Máximo de crédito aplicable mensualmente
• Procedimiento de reclamación (plazo, documentación, canal)
• Confirmación de que los créditos son el único remedio salvo pacto expreso

Gobernanza y revisión

• Cadencia de reporting (mensual recomendado)
• Cadencia de revisión formal del SLA (trimestral recomendado)
• Responsables del proceso de revisión (RACI mínimo)
• Acceso del cliente a los datos de medición

Caso de uso: SLA para una plataforma SaaS B2B

Una empresa del sector logístico con operaciones en España y Portugal contrató a abemon la gestión de su plataforma de seguimiento de envíos en tiempo real, utilizada por 120 clientes B2B para monitorizar más de 15.000 envíos diarios.

El SLA inicial tenía dos problemas: prometía “disponibilidad del 99,9%” sin ventana de medición y el tiempo de respuesta para incidencias críticas era de “4 horas hábiles”, lo que en la práctica equivalía a hasta 16 horas en fin de semana para un sistema que operaba 24x7.

Tras la revisión, el SLA rediseñado estableció: disponibilidad del 99,9% medida en ventanas deslizantes de 30 días desde tres sondas externas; tiempo de respuesta para P1 de 30 minutos naturales (sin distinción entre horas hábiles y no hábiles); tiempo de resolución objetivo para P1 de 4 horas; tabla de créditos con máximo del 25% de la factura mensual. Se instrumentaron dashboards en Datadog con alertas automáticas al 70% y 90% de consumo del error budget mensual.

En los 12 meses siguientes al rediseño, la plataforma mantuvo una disponibilidad media del 99,96%, se gestionaron 3 incidencias P2 con MTTR de 47 minutos de media y los clientes no presentaron ninguna reclamación de crédito. La transparencia del dashboard compartido redujo las consultas de incidencia en un 60%.

Fuentes

1. AXELOS / ITIL — ITIL 4 Foundation: IT Service Management Framework
2. BOE — Real Decreto 311/2022: Esquema Nacional de Seguridad
3. EUR-Lex — Reglamento (UE) 2022/2554 — DORA: resiliencia operativa digital del sector financiero
4. AWS — Amazon Web Services Service Level Agreements
5. Microsoft — Azure Service Level Agreements Summary
6. Google Cloud — Google Cloud SLAs
7. DORA / Google — Accelerate State of DevOps Report — DORA metrics
8. ISO — ISO/IEC 20000-1:2018 Service Management System Requirements

abemon gestiona SLAs para organizaciones que no pueden permitirse papel mojado

En abemon diseñamos, instrumentamos y operamos acuerdos de nivel de servicio para plataformas digitales críticas. Nuestro servicio de managed services incluye SLOs documentados, dashboards compartidos y revisiones trimestrales formales. Para proyectos de plataforma o arquitectura cloud, trabajamos con los equipos de tecnología desde el diseño hasta la operación continua.

Si está revisando los contratos de nivel de servicio de su organización o necesita establecer compromisos medibles con sus clientes, puede consultar nuestros servicios de consultoría y transformación o ponerse en contacto directamente con nuestro equipo desde la página de contacto.

Para profundizar en la instrumentación de plataformas, la guía sobre observabilidad en microservicios y el análisis de procesos SLA en el contexto de managed services complementan los conceptos de esta guía.