SLA de Alojamiento: Uptime y Ventana de Mantenimiento Explicados

El SLA de alojamiento es la sección del contrato que especifica cuánto tiempo puede estar inactivo su sitio web o sistema sin que el proveedor le deba nada. Parece un detalle jurídico, pero es lo que decide si una caída un martes por la tarde se convierte en crédito, multa o solo una disculpa por correo electrónico. En esta guía explico, en español claro, el uptime, el SLA y la ventana de mantenimiento, con cifras reales y la letra pequeña que más afecta al cliente.

TL;DR

El 99,9% de uptime permite aproximadamente 43 minutos de caída al mes. El 99,5% permite 3 horas y 36 minutos. La diferencia de un "nueve" es enorme.

El SLA de alojamiento casi nunca cubre su perjuicio: devuelve un porcentaje de la mensualidad en crédito. En AWS, una instancia EC2 que cae por debajo del 99,5% genera un 10% de crédito.

El mantenimiento programado suele quedar fuera del cálculo del uptime. Lea cómo el contrato define la ventana y con cuánta antelación se avisa.

Un sistema depende de varios servicios. Tres componentes del 99,9% en serie entregan aproximadamente el 99,7% en total.

Lo que más importa, además del porcentaje: tiempo de respuesta, tiempo de resolución y tiempo de restauración de la copia de seguridad escritos en el contrato.

Qué es el SLA de alojamiento (y qué no es)

SLA es la sigla de Service Level Agreement, el acuerdo de nivel de servicio. En el SLA de alojamiento, el contrato formaliza tres cosas: qué métrica promete el proveedor (normalmente el uptime mensual), cómo se mide esa métrica y qué sucede cuando no se cumple.

En el día a día de quien opera un servidor, tres siglas aparecen juntas:

SLI (indicator): el número medido en realidad. Ejemplo: el sitio web respondió al 99,94% de las comprobaciones en el mes.
SLO (objective): la meta interna del equipo. Ejemplo: queremos el 99,95%.
SLA (agreement): la promesa contractual, normalmente más holgada que el SLO, porque incumplirla cuesta dinero.

Uptime y disponibilidad no son exactamente lo mismo

El Uptime es el porcentaje del tiempo en que el servicio estuvo activo. La Disponibilidad, en el sentido más riguroso, es el porcentaje del tiempo en que estuvo utilizable para el usuario. Un servidor puede estar encendido, con el ping respondiendo, mientras la base de datos se bloqueó y la página devuelve un error 500. Para el proveedor de infraestructura, esto puede contar como uptime. Para su cliente, el sitio web se cayó.

Por eso, la primera pregunta al leer un SLA de alojamiento es: ¿qué se está midiendo exactamente? ¿El servidor? ¿La red? ¿La respuesta HTTP de su aplicación?

El SLA no es una garantía de que nada se caerá

Esta es la equivocación más común sobre el SLA de alojamiento en contratos de pequeñas y medianas empresas. Un SLA de alojamiento del 99,9% no dice que el sitio web no se caerá. Dice cuánta caída considera aceptable el proveedor y qué compensación ofrece si se excede. Quien compra alojamiento pensando que el SLA es un seguro contra pérdidas se decepciona en la primera caída seria.

Cuánto tiempo inactivo permite cada "nueve"

La forma más honesta de comparar un SLA de alojamiento con otro es convertir el porcentaje en minutos. El cálculo a continuación utiliza un mes de 30 días (43.200 minutos) y un año de 365 días:

Uptime prometido	Caída permitida al mes	Caída permitida al año
99%	7 h 12 min	3 días y 15 h 36 min
99,5%	3 h 36 min	1 día y 19 h 48 min
99,9%	43 min 12 s	8 h 45 min 36 s
99,95%	21 min 36 s	4 h 22 min 48 s
99,99%	4 min 19 s	52 min 34 s

Observe el salto. Pasar del 99,5% al 99,9% reduce la caída tolerada de más de tres horas y media a menos de 45 minutos al mes. De 99,9% a 99,99% la diferencia es de 43 minutos a 4, y ese último nueve es el más caro de todos, porque exige redundancia real.

Un ejemplo práctico con Moodle

Piense en una plataforma Moodle con un examen online programado para las 19h. Un contrato del 99,5% permite que el entorno permanezca inactivo 3 horas y media en ese mes sin ninguna violación. Si esas 3 horas caen exactamente en la ventana del examen, el proveedor cumplió el SLA y la institución tendrá que reprogramar la evaluación, atender las quejas de los alumnos y explicar el problema a la coordinación. En los entornos Moodle que administramos, por eso miramos primero cuándo puede ocurrir la caída, y no solo cuánto.

Cómo leer un SLA de alojamiento: las cláusulas que importan

Antes de firmar cualquier SLA de alojamiento, busque estos puntos en el contrato. Si alguno de ellos no está escrito en el SLA de alojamiento que recibió, no existe.

Métrica y forma de medición. ¿Quién mide? ¿El propio proveedor o una herramienta externa? ¿En qué intervalo? Una comprobación cada 5 minutos no detecta caídas de 3 minutos.
Período de cálculo. Mensual es el estándar. El SLA anual diluye una caída grande en doce meses y casi nunca activa una compensación.
Exclusiones. Fuerza mayor, ataques DDoS, fallo de terceros, error del propio cliente y mantenimiento programado aparecen en casi todo contrato. El problema es cuando la lista es tan amplia que queda poco cubierto.
Definición de mantenimiento programado. ¿Con cuánta antelación se avisa? ¿Cuál es la duración máxima? ¿En qué horario? Sin límite escrito, toda caída puede convertirse en mantenimiento.
Compensación. ¿Crédito en la factura, descuento o multa? ¿Cuál es el tope? ¿Es automática o debe solicitarse?
Plazo para reclamar. Algunos proveedores exigen que el cliente abra una incidencia en pocos días o al mes siguiente. Perdió el plazo, perdió el crédito.
Tiempo de respuesta y de resolución por severidad. Esta es la cláusula que más marca la diferencia en la práctica, y la que más falta en los planes estándar.
Copia de seguridad y restauración. ¿Con qué frecuencia se realiza la copia de seguridad (el RPO, o cuántos datos está dispuesto a perder) y en cuánto tiempo el entorno vuelve (el RTO, o cuánto tiempo está dispuesto a estar inactivo).

Ejemplo real de cláusula de compensación

El centro de ayuda de Locaweb (un proveedor brasileño) informa un SLA mensual del 99,5% para los planes de alojamiento compartido, con descuento escalonado: 5% cuando la disponibilidad se sitúa entre 99,0% y 99,4%, 10% entre 95,0% y 98,9%, 20% entre 90,0% y 94,9% y 30% por debajo del 89,9%. Y el cliente debe solicitar el cálculo abriendo una incidencia a principios del mes siguiente. Es un modelo transparente y común en el mercado, y muestra bien la lógica: la compensación es proporcional a la mensualidad, no al daño.

Crédito de servicio: por qué el SLA no cubre su perjuicio

Vea cómo funciona el SLA de alojamiento en el mayor proveedor de nube del mundo. El SLA de Amazon EC2 tiene dos niveles:

Por instancia: 99,5% de uptime mensual. Por debajo de eso y hasta el 99,0%, el crédito es del 10%. Entre 99,0% y 95,0%, 30%. Por debajo del 95%, 100%.
Por región: 99,99%, pero solo para quien distribuye instancias en dos o más zonas de disponibilidad de la misma región.

En otras palabras: una única máquina en AWS, sola, tiene una promesa del 99,5%, la misma franja que un alojamiento compartido. El 99,99% solo existe cuando paga por redundancia. Y lo que recibe es crédito sobre la factura de esa instancia.

Ahora compare con el coste de estar inactivo. El informe anual de caídas del Uptime Institute de 2025 señala que el 54% de los entrevistados dijo que la última caída significativa costó más de 100.000 USD, y el 20% reportó un coste superior a 1 millón de USD. La empresa media española no está en esa escala, pero la proporción es válida: si el servidor cuesta 300 € al mes, el crédito máximo del 10% es de 30 €. Una tarde de e-commerce parado, un día de matrícula inactivo o una atención al cliente por WhatsApp sin respuesta cuestan mucho más que eso.

Conclusión práctica: el crédito previsto en el SLA de alojamiento es un incentivo para el proveedor, no un seguro para usted. Lo que protege su negocio es la arquitectura (redundancia, copia de seguridad probada, monitorización) y el equipo que responde cuando algo sale mal. Es exactamente esa capa la que un alojamiento gestionado con SLA contractual cubre y una VPS sola no cubre.

Ventana de mantenimiento: cuándo realizarla y cuándo no

En el SLA de alojamiento, la ventana de mantenimiento es el período acordado en el que el proveedor puede actualizar el sistema operativo, PHP, la base de datos, el kernel o el hardware, con riesgo de indisponibilidad. Es necesaria: un servidor sin actualización es un servidor vulnerable. El problema es cuando se utiliza como excusa.

Cuándo realizarla

En el horario de menor tráfico real de su público, y no en el horario conveniente para el proveedor. Para la mayoría de los sitios web españoles es la madrugada del domingo al lunes, pero una plataforma de posgrado nocturno o un e-commerce que vende para Portugal tiene otro perfil. Mire el gráfico de accesos antes de elegir.
Con entorno de pruebas (staging) previo. La actualización de PHP o de la base de datos probada en una copia del entorno reduce el tiempo de la ventana de horas a minutos.
Con aviso previo. En los entornos que administramos, la regla es avisar con antelación, informar la duración estimada y el plan de reversión.
Con parche crítico de seguridad. Cuando se publica una CVE grave y explotada, la ventana puede necesitar ser anticipada. Aquí la velocidad vale más que el horario perfecto.

Cuándo NO realizarla

Semana de exámenes o de matrícula en instituciones educativas. En Moodle, congelamos las actualizaciones no urgentes en esos períodos.
Black Friday, lanzamientos y campañas de pago activas. Manipular la infraestructura con tráfico comprado llegando es quemar presupuesto.
Cierre de mes para ERP, sistemas financieros y emisión de facturas.
Viernes por la tarde. Si la actualización sale mal, el equipo necesita estar descansado y disponible para revertir, y no empezando el fin de semana.

Moodle ayuda: modo de mantenimiento

En Moodle, active el modo de mantenimiento antes de actualizar. Muestra un mensaje a los alumnos y mantiene el acceso de los administradores. Parece obvio, pero ya hemos recibido entornos de otro proveedor en los que la actualización se realizaba con la plataforma abierta, con alumnos en medio de un cuestionario. Si el cambio implica cambiar de servidor, el cuidado es mayor; detallé el proceso en cómo migrar Moodle de servidor sin perder datos.

SLA compuesto: la cadena es tan fuerte como su eslabón más débil

Su sistema rara vez depende de un solo servicio. Un sitio web típico pasa por DNS, CDN, servidor web, base de datos, servicio de correo electrónico transaccional y, cada vez más, APIs de terceros. Cuando estos componentes están en serie (si uno falla, todo falla), las disponibilidades se multiplican:

99,9% × 99,9% × 99,9% = 99,7%, o aproximadamente 2 horas y 10 minutos de caída tolerada al mes.
Con cinco componentes del 99,9%, el resultado cae a aproximadamente el 99,5%.

En la práctica, esto significa que el SLA de alojamiento del servidor no es el SLA de su negocio. Un ejemplo que vivimos en integraciones con la API oficial de WhatsApp: el servidor puede estar 100% activo y, aun así, la atención al cliente se detenga porque Meta tuvo inestabilidad, porque el token expiró o porque el webhook se quedó sin respuesta. Un buen diseño de infraestructura trata estos puntos con cola, nuevo intento automático y alerta, para que un fallo externo no derribe el resto.

Cómo aumentar la disponibilidad sin multiplicar el coste

Coloque redundancia solo donde duele. Una base de datos con réplica y failover suele ser la mayor ganancia por euro invertido.
Use CDN por delante. Un CDN sirve páginas en caché incluso durante una caída corta del origen. El SLA Business de Cloudflare, por ejemplo, promete el 100% de uptime para clientes del plan Business.
Monitorice desde fuera. La medición tiene que venir de un punto externo a su servidor; si no, cuando este cae, el monitor cae con él.

Trampas comunes en el SLA de alojamiento

Estas son las que más encuentro al revisar el SLA de alojamiento de clientes que llegan de otro proveedor:

"Uptime de red" vendido como uptime del sitio web. El enlace estaba activo; su WordPress, no. Lea qué se mide.
Mantenimiento sin límite. Contrato que excluye el mantenimiento programado sin limitar la duración ni exigir aviso. En la práctica, cualquier caída puede ser reclasificada.
Compensación que exige una incidencia con plazo corto. Usted solo descubre que tenía derecho cuando el plazo ha pasado.
Soporte sin tiempo de resolución. "Respuesta en 15 minutos" que significa un robot diciendo que recibió la incidencia.
Copia de seguridad sin prueba de restauración. La copia de seguridad existe, pero nadie la ha restaurado nunca. El día de la necesidad, el archivo está corrupto o incompleto.
SLA que no cubre su código. Plugin desactualizado, consulta lenta en la base de datos o error de despliegue derriban el sitio web, y nada de eso es responsabilidad del proveedor de infraestructura pura.
Permanencia larga con SLA débil. Si el servicio no cumple, usted no puede irse sin multa.

Gran parte de estas trampas desaparece cuando queda claro quién se encarga de qué. Hice una comparación directa en alojamiento gestionado vs VPS: quién se encarga de qué cuando el sitio web cae. Y, como una caída por intrusión también es una caída, vale la pena revisar la checklist de hardening de servidor Linux.

Cuánto cuesta subir un nueve (y cuándo no vale la pena)

Cada nueve adicional en el SLA de alojamiento cuesta más que el anterior. La regla aproximada que usamos al hablar con clientes:

Meta	Lo que normalmente exige	Para quién tiene sentido
99,5%	Servidor único, copia de seguridad diaria, monitorización básica	Sitio web institucional, blog, landing page
99,9%	Servidor bien dimensionado, CDN, monitorización 24/7, equipo de guardia, parches en ventana	E-commerce pequeño, Plataforma Moodle, sistemas internos
99,95%	Base de datos con réplica y failover, despliegue sin tiempo de inactividad	SaaS, ERP, operación que vende o atiende todo el día
99,99%	Múltiples zonas, balanceo, failover automático probado	Operación en la que minutos inactivos cuestan mucho

Cuándo NO vale la pena pagar por un nueve adicional

Cuando el tráfico es comercial y el público no usa el sistema de madrugada. Una caída a las 4h de un domingo no la ve nadie.
Cuando el cuello de botella es la aplicación. Si su sistema cae por código o plugin, la redundancia de servidor solo duplica el problema.
Cuando el coste de la caída es menor que el de la redundancia. Haga la cuenta: ¿cuánto pierde por hora inactivo? Multiplique por las horas extra toleradas en el nivel actual. Si da menos que la diferencia de mensualidad, el nueve extra es un lujo.

Antes de pagar por el 99,99% en el SLA de alojamiento de su servidor, casi siempre vale más la pena garantizar un tiempo de respuesta corto y una copia de seguridad probada. En la mayoría de las caídas que atendemos, lo que define el daño no es el porcentaje del contrato, sino cuántos minutos tarda el equipo en darse cuenta y actuar.

Cómo Agathas Web resuelve esto

Operamos servidores Linux, entornos Moodle y sistemas a medida desde 2008. Nuestro alojamiento gestionado tiene un SLA de alojamiento que responde a las preguntas de esta guía por escrito, en el contrato:

Uptime mensual del 99,9% (hasta aproximadamente 43 minutos al mes), medido por monitorización externa 24/7.
Respuesta a incidente crítico en hasta 15 minutos y resolución en hasta 2 horas, con runbook por tipo de incidente.
Copia de seguridad diaria más incremental, cifrada y fuera del servidor, con restauración probada cada mes y restauración de las últimas 24 horas en hasta 4 horas.
Parche crítico en hasta 72 horas tras CVE pública, siempre pasando por entorno de pruebas (staging) y en ventana de mantenimiento combinada con usted, respetando semana de exámenes, campaña y cierre.
Multa contractual si incumplimos el SLA, e informe mensual con uptime, incidentes y copias de seguridad probadas.
Sin permanencia: contrato mensual con 30 días de aviso.

En la práctica, la atención es realizada por quien opera el entorno, con canal directo en WhatsApp. Para contratar, usted pide un diagnóstico gratuito de la infraestructura actual: analizamos el contrato y la arquitectura que tiene hoy, señalamos riesgos y, si tiene sentido, migramos en hasta 7 días hábiles, con entorno de pruebas (staging), ventana de bajo tráfico y plan de reversión. Si su caso es una plataforma Moodle, la página de alojamiento Moodle tiene los detalles específicos.

Conclusión: pregunte en minutos, no en porcentajes

El SLA de alojamiento solo es útil cuando lo traduce en minutos, cláusulas y responsables. Convierta el porcentaje en tiempo de caída, descubra qué se mide, vea cómo se trata el mantenimiento programado y, principalmente, cuánto tiempo tarda el equipo en responder y restaurar. El crédito en la factura es el menor de los beneficios; lo que protege el negocio es una arquitectura bien hecha y gente atenta cuando la alerta suena.

Si usted quiere un contrato en el que esos números estén escritos, con multa si no se cumplen, conozca el alojamiento gestionado de Agathas Web y pida el diagnóstico gratuito de su entorno.