Garantías de tiempo de actividad y SLA explicadas

Qué significan realmente el uptime y un SLA

El uptime es la proporción de tiempo en que un servicio está disponible y funcionando. Un acuerdo de nivel de servicio (SLA, por sus siglas en inglés) es el documento contractual en el que un proveedor define cómo se mide la disponibilidad, qué nivel se compromete a ofrecer y qué ocurre cuando no lo cumple. Las empresas de hosting, las plataformas cloud, los proveedores de DNS y las CDN publican SLA, y la cifra principal, como 99,9 % o 99,99 %, suele aparecer de forma destacada en las páginas de precios.

Esa cifra es útil, pero solo es el punto de partida. Dos proveedores que anuncian el mismo porcentaje pueden ofrecer una protección muy distinta según cómo midan la disponibilidad, qué excluyan y cómo se reclame la compensación. Esta guía explica cómo leer los números y la letra pequeña, y cómo protegerte digas lo que diga el SLA.

Traducir porcentajes a tiempo de caída

Los porcentajes cercanos al 100 parecen similares, pero el tiempo de caída que permiten varía muchísimo. La tabla siguiente convierte los niveles de uptime más comunes en el tiempo máximo de caída permitido en un mes medio (unos 30,4 días) y en un año (365,25 días). Los valores están redondeados.

Puedes calcular cualquier valor tú mismo: multiplica los minutos del periodo por uno menos la fracción de uptime. Para un mes de 30 días al 99,9 %, son 43.200 × 0,001 = 43,2 minutos.

Fíjate en que la ventana de medición importa. Un SLA mensual se reinicia cada mes, de modo que una caída larga a principios de año no agota un presupuesto anual. En cambio, un SLA medido anualmente podría, en teoría, permitir varias horas de caída de una sola vez y seguir cumpliéndose.

Cómo miden los proveedores la disponibilidad

La definición de “disponible” es donde más se diferencian los SLA. Lee con atención el apartado de medición y busca respuesta a estas preguntas:

• ¿Qué se mide? ¿El servidor físico, la red, el servidor web respondiendo a HTTP o tu aplicación real? Un proveedor puede cumplir un SLA de red mientras tu web devuelve errores.
• ¿Quién lo mide? La mayoría de los SLA se basan en la monitorización del propio proveedor, no en la tuya. Algunos exigen que aportes pruebas.
• ¿Con qué frecuencia se comprueba? Una comprobación cada cinco minutos puede pasar por alto por completo las caídas cortas.
• ¿Cuál es la duración mínima de una caída? Algunos acuerdos solo cuentan incidencias que duran más de un número determinado de minutos.
• ¿Cuenta la degradación parcial? Las respuestas muy lentas o los errores solo en algunas peticiones pueden no considerarse caída.

SLA por componente y disponibilidad combinada

Tu web depende de varios servicios encadenados: el registro del dominio, el DNS, el hosting, la base de datos, la CDN y las API de terceros. Si cada componente es independiente y todos deben funcionar, la disponibilidad total es aproximadamente el producto de las cifras individuales. Dos componentes al 99,9 % cada uno dan alrededor de un 99,8 % combinado. Añadir redundancia, como un proveedor de DNS secundario, puede mejorar el resultado, mientras que sumar más puntos únicos de fallo lo empeora.

Exclusiones habituales en la letra pequeña

Casi todos los SLA excluyen ciertos eventos del cálculo del tiempo de caída. Las exclusiones típicas incluyen:

• Mantenimiento programado anunciado con antelación, a veces dentro de una ventana definida.
• Problemas causados por el propio código del cliente, su configuración o el exceso de los límites de recursos.
• Ataques como la denegación de servicio distribuida, según el proveedor.
• Fallos de redes o servicios de terceros fuera del control del proveedor.
• Causas de fuerza mayor, como desastres naturales.
• Suspensión por impago o por incumplimiento de las políticas.

Las exclusiones no son necesariamente injustas, pero cambian el significado real de la cifra anunciada. Una exclusión generosa por mantenimiento, por ejemplo, puede permitir caídas planificadas regulares que nunca cuentan contra la garantía. En un hosting compartido, superar los límites de CPU o de procesos de tu cuenta suele considerarse un problema tuyo y no del proveedor, que es una de las razones por las que nuestra guía sobre la configuración del hosting compartido presta atención a los límites de recursos.

Créditos de servicio y qué puedes reclamar

Cuando un proveedor no alcanza su objetivo, la compensación habitual es un crédito de servicio: un porcentaje de la cuota mensual que se aplica a una factura futura. Los tramos de crédito suelen escalar según cuánto haya caído la disponibilidad, y muchos SLA limitan el total de créditos a una parte, o como máximo a la totalidad, de la cuota mensual del servicio afectado. Las condiciones varían, así que consulta siempre la tabla exacta de tu proveedor.

De esta estructura se derivan algunas consecuencias prácticas:

1. Los créditos son pequeños frente a las pérdidas del negocio. Si tu hosting cuesta una cuota mensual modesta, el crédito máximo se limita a esa cantidad aunque una caída te cueste mucho más en ventas perdidas.
2. Los créditos rara vez son automáticos. Muchos proveedores exigen abrir un ticket dentro de un plazo fijo tras la incidencia, a veces con registros o pruebas de monitorización.
3. Los créditos suelen excluir los daños indirectos. Las condiciones de servicio estándar suelen limitar la responsabilidad a las cuotas pagadas.

Esto no es asesoramiento legal; las condiciones contractuales varían según el proveedor y la jurisdicción. En servicios de alto valor, los clientes grandes a veces pueden negociar condiciones personalizadas, pero la mayoría de los planes compartidos y VPS usan acuerdos estándar no negociables.

Monitorizar el uptime por tu cuenta

Como los proveedores miden su propio rendimiento, la monitorización independiente es la mejor forma de saber lo que realmente experimentan tus visitantes. Un monitor externo solicita tu web desde fuera de la red del hosting a intervalos regulares y registra el código de respuesta, el tiempo de respuesta y los posibles errores.

Una comprobación manual rápida desde la línea de comandos muestra el código de estado y el tiempo total de respuesta:

curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com/

Para una monitorización continua, un servicio externo o un pequeño script programado con cron es más fiable que las comprobaciones manuales. Algunas buenas prácticas:

• Comprueba desde más de una ubicación para que un problema en una sola ruta de red no genere falsas alarmas.
• Monitoriza una página que use tu aplicación y tu base de datos, no solo un archivo estático.
• Comprueba que aparece el contenido esperado, ya que una página de error puede devolver igualmente un estado 200.
• Conserva el historial de alertas, que te servirá de prueba al presentar una reclamación del SLA.

Caídas que ningún SLA de hosting cubre

Algunas de las causas más comunes de caída son administrativas y no técnicas: un dominio caducado, un certificado SSL vencido o una factura de hosting sin pagar. Ningún SLA de hosting compensa estos casos. TLDix ayuda aquí controlando las fechas de renovación de dominios, SSL y hosting y enviando alertas de caducidad; puedes añadir tus activos en el panel de dominios y leer más sobre cómo evitar vencimientos en nuestra guía para prevenir la caducidad de dominios.

Prepararse para una caída antes de que ocurra

Una buena monitorización es más valiosa cuando va acompañada de un plan de respuesta sencillo. Anota quién recibe las alertas, cómo contactar rápidamente con el soporte del proveedor, dónde está su página de estado y qué dirás a tus clientes si la web no está disponible durante un periodo prolongado. Guarda los datos de acceso del registrador, del proveedor de DNS y del panel de hosting en un gestor de contraseñas seguro que no dependa de la propia web. Después de cada incidencia, anota la hora de inicio y de fin, la causa que comunicó el proveedor y si presentaste una reclamación de crédito. Con los meses, este registro muestra si el proveedor cumple sus promesas de forma constante y te da datos sólidos si decides cambiar de hosting.

Elegir el nivel de uptime adecuado

Las garantías más altas suelen costar más y, a menudo, exigen cambios de arquitectura y no solo otro plan. Ajusta el objetivo al coste real de una caída:

Estos rangos son orientaciones generales, no normas del sector. El objetivo adecuado depende de tus ingresos por hora, de las expectativas de tus clientes y de los contratos que tengas con ellos.

Preguntas que hacer antes de contratar

Antes de comprometerte con un proveedor, pregunta o consulta lo siguiente:

• ¿El SLA se mide mensual o anualmente, y qué cuenta exactamente como caída?
• ¿Con cuánta antelación se avisa del mantenimiento programado y está excluido?
• ¿Cómo se calculan, limitan y reclaman los créditos, y en qué plazo?
• ¿Publica el proveedor una página de estado pública y un historial de incidencias?
• ¿Qué tiempos de respuesta del soporte se aplican durante una caída?

Un SLA claro y concreto con una página de estado transparente suele ser mejor señal que un porcentaje muy alto rodeado de exclusiones amplias. Combina una garantía razonable con tu propia monitorización, copias de seguridad externas y seguimiento de renovaciones, y estarás protegido frente a muchos más tipos de fallo de los que cubre el SLA por sí solo.