El SLA de hosting es mucho más que un porcentaje puesto en una web para convencer al cliente: es un contrato de confianza. En Grupo Novalca llevamos años gestionando infraestructura crítica para clientes en España y México, y he aprendido que la diferencia entre un SLA que se cumple y uno que acaba en conflicto casi nunca está en la tecnología. Está en cómo se redactó desde el principio. En este artículo te lo cuento desde la posición de quien los firma y los ejecuta: cómo escribir un SLA de hosting que puedas cumplir de verdad.
Qué es un SLA de hosting y por qué la mayoría está mal redactado
Un SLA (Service Level Agreement, o acuerdo de nivel de servicio) es el compromiso formal entre el proveedor de hosting y el cliente sobre qué nivel de servicio se va a recibir: disponibilidad, tiempos de respuesta, ventanas de mantenimiento y, en muchos casos, compensaciones si no se cumple.
Hasta ahí, todo claro. El problema es otro. La mayoría de los SLA que veo en el sector tienen tres defectos graves:
- No definen qué cuenta como indisponibilidad. ¿Un servicio de correo caído pero la web operativa es downtime? ¿Y una web que tarda 15 segundos en cargar? Si no lo especificas, cada parte lo interpretará a su favor. Siempre.
- No indican cómo se mide. ¿Desde dónde? ¿Cada cuánto? ¿Qué herramienta hace fe? Sin esto, la métrica es una opinión, no un contrato.
- Detallan la compensación pero no las exclusiones. El cliente lee «99,9% garantizado» y asume que aplica a todo, cuando en la letra pequeña se excluyen ataques DDoS, fallos de software del propio cliente o mantenimientos programados.
Un SLA mal redactado no protege a nadie. Genera falsas expectativas en el cliente y riesgo legal para el proveedor.
El error más común: prometer un 99,99% que no puedes garantizar
Pongamos números, porque aquí es donde el sector se engaña a sí mismo. Un 99,99% de disponibilidad anual equivale a unos 52 minutos de caída en todo el año. Un 99,9%, en cambio, son unas 8 horas y 45 minutos.
He visto a pequeños proveedores prometer cuatro nueves sin tener siquiera redundancia eléctrica en su oficina. Es una bomba de relojería. Cuando caes —y caes—, además del daño reputacional, te enfrentas a compensaciones acumuladas que pueden superar el valor del propio contrato.
Mi consejo tras años en esto:
- Calcula tu disponibilidad real de los últimos 12 meses antes de prometer nada. No la que crees tener: la medida.
- Promete un punto por debajo de tu media. Si llevas un 99,95% real, ofrece 99,9%. Ese margen es tu colchón ante lo imprevisto.
- Documenta cada incidencia desde el primer día. Sin registro histórico no puedes demostrar nada. Ni mejorar, por cierto.
Es mejor firmar un 99,9% que cumples con orgullo que un 99,99% que conviertes en descuento cada trimestre.
Cómo medir la disponibilidad y definir métricas realistas
Aceptado que la métrica debe ser realista, toca definirla con precisión. Estos son los elementos que todo SLA de hosting debería especificar:
- Método de medición: herramientas de monitorización externa (tipo UptimeRobot, Pingdom o Zabbix) desde al menos dos ubicaciones geográficas distintas.
- Intervalo de comprobación: cada 1 o 5 minutos. Un chequeo cada 15 puede ocultar caídas completas.
- Definición de downtime: por ejemplo, «más de 3 comprobaciones consecutivas fallidas desde ambas ubicaciones».
- Periodo de cálculo: mensual es lo habitual y lo más justo; el anual diluye las incidencias y complica las compensaciones.
- Métricas complementarias: tiempo de respuesta del servidor (TTFB) y tiempos máximos de respuesta a tickets, que en la práctica preocupan al cliente tanto como la propia caída.
Tip práctico: incluye en el SLA un ejemplo de cálculo. «Ejemplo: en un mes de 30 días, el 99,9% permite 43 minutos de indisponibilidad». Con eso eliminas el 90% de las discusiones futuras. De verdad.
Con métricas claras, medibles y verificables por ambas partes, tu SLA deja de ser un texto de marketing y se convierte en lo que debe ser: un compromiso serio que refuerza la relación con tu cliente.
Tiempos de respuesta, soporte y compensaciones: qué incluir en tu SLA de hosting
El uptime es solo la mitad del SLA de hosting. La otra mitad —y la que más tensiones genera— es todo lo relacionado con el soporte. Si no defines cómo y cuándo vas a responder, cualquier incidencia acaba convertida en una discusión sobre expectativas. Por eso el acuerdo debe concretar, como mínimo, tres cosas: canales habilitados, tiempos de respuesta y compensaciones.
Define los tiempos de respuesta, no los de resolución
Un error frecuente: comprometer «resolución en 2 horas». Nadie puede garantizar cuánto tarda en arreglarse un problema complejo. Lo que sí puedes garantizar es el tiempo de primera respuesta y el de escalado. Por ejemplo:
- Incidentes críticos (servidor caído, datos inaccesibles): primera respuesta en 15 minutos, 24/7.
- Incidentes graves (degradación severa del servicio): primera respuesta en 1 hora.
- Incidencias normales (configuraciones, dudas técnicas): primera respuesta en 4 horas laborables.
- Consultas generales: primera respuesta en 1 día laborable.
Compensaciones: realistas y automáticas
La compensación debe ser proporcional, fácil de calcular y, a ser posible, automática. Si el cliente tiene que reclamar para recibir un crédito, el SLA pierde todo su valor comercial. Un esquema habitual es devolver un porcentaje de la cuota mensual según el tiempo de indisponibilidad acumulado, con un toque de realidad: excluye las paradas programadas comunicadas con antelación y las causas de fuerza mayor. Eso no es esconderse. Es honestidad contractual, y los clientes lo agradecen más de lo que parece.
Ejemplo práctico: cómo estructuramos el SLA en Grupo Novalca
En Grupo Novalca aprendimos esto a base de equivocarnos. Nuestro primer SLA, allá por los inicios, prometía un 99,99% de disponibilidad que no podíamos sostener con la infraestructura de entonces. Cumplirlo dependía de la suerte. Hoy estructuramos cada acuerdo en cuatro bloques:
- Alcance y definiciones: qué servicio cubre el acuerdo, qué es «indisponibilidad», qué queda fuera (mantenimientos programados, aplicaciones del propio cliente).
- Compromisos medibles: disponibilidad mensual, tiempos de primera respuesta por nivel de severidad y ventana de mantenimiento notificada con al menos 72 horas.
- Medición y transparencia: panel de estado público y mensualizado, con la fuente de datos que ambos aceptamos como válida. Sin métrica verificable, no hay compromiso.
- Compensaciones: créditos automáticos sobre la siguiente factura si no se cumple el objetivo, sin necesidad de reclamación.
El resultado fue contraintuitivo. Al bajar el compromiso de 99,99% a un 99,9% que sí cumplíamos, las quejas bajaron y la confianza subió. Los clientes no premian la promesa más espectacular; premian la que se cumple.
Conclusión: un SLA creíble vale más que un SLA espectacular
Redactar un SLA de hosting no es un ejercicio de marketing: es una declaración de cómo operas. Un compromiso del 99,99% que incumplen otros te costará clientes; un 99,9% sostenido con datos transparentes te los fideliza. Define métricas verificables, tiempos de respuesta realistas por severidad, compensaciones automáticas y exclusiones claras. Y revisa el acuerdo cada año: tu infraestructura mejora, y tu SLA debe reflejarlo. La mejor venta que puedes hacer no es prometer perfección, sino demostrar, mes a mes, que cumples lo que firmaste.