Uptime y SLA del 99,9%: qué significan en la práctica

"99,9% de uptime" aparece en casi todas las páginas de hosting. El número suena a garantía de que el servicio casi nunca se cae, pero dice poco sin dos datos más: en qué período se mide y qué pasa cuando no se cumple.

Antes de depender de él, conviene saber hacer el cálculo y distinguir una meta interna de un contrato con compensación.

¿Qué es el uptime?#

El uptime es el porcentaje del tiempo en que un servicio estuvo disponible dentro de un período. La fórmula es sencilla:

uptime = (tiempo total - tiempo caído) / tiempo total x 100

Si una app estuvo caída 20 minutos en un mes de 30 días (43.200 minutos), el uptime fue del 99,954%. La medida solo tiene sentido con una definición clara de "disponible". Puede ser responder HTTP 200 en menos de 5 segundos, aceptar una conexión TCP o, en el caso de un bot, seguir conectado al Gateway. Cada definición da un número distinto para el mismo incidente.

¿Cuánto downtime permite cada porcentaje?#

Para obtener el downtime permitido, multiplica el período por la fracción de indisponibilidad (100% menos el uptime):

Puedes rehacer el cálculo para cualquier valor en Node.js:

const minutosEnElMes = 30 * 24 * 60; // 43200

for (const uptime of [99, 99.9, 99.99, 99.999]) {
  const downtime = minutosEnElMes * (1 - uptime / 100);
  console.log(`${uptime}% -> ${downtime.toFixed(2)} min/mes`);
}

Cada "nueve" adicional divide el downtime permitido entre diez. El libro de SRE de Google describe cada nueve adicional como una mejora de un orden de magnitud hacia el 100%, y afirma que el 100% probablemente nunca es la meta correcta de confiabilidad.

¿Qué diferencia hay entre SLI, SLO y SLA?#

Los tres términos se confunden, pero describen capas distintas:

• SLI (indicador de nivel de servicio): lo que mides. Ejemplo: la fracción de peticiones respondidas con éxito.
• SLO (objetivo de nivel de servicio): la meta interna para el SLI. Ejemplo: el 99,9% de las peticiones con éxito en 30 días. Lo define el equipo que opera el servicio.
• SLA (acuerdo de nivel de servicio): el contrato con el cliente. Incluye un SLO y las consecuencias de incumplirlo.

En la práctica, un SLO es una meta, y un SLA es una meta con compensación económica. Ninguno de los dos impide la caída. El libro de SRE también presenta el presupuesto de errores: el downtime que el SLO tolera. Con un SLO del 99,9% medido en 30 días, el presupuesto es de 43,2 minutos, y el equipo puede "gastarlo" en deploys y mantenimiento en lugar de perseguir el cero.

¿Qué garantiza realmente un SLA?#

Casi siempre, un SLA garantiza una compensación, no la disponibilidad. Toma como ejemplo el formato del SLA regional de Amazon EC2: un compromiso de disponibilidad por ciclo mensual de facturación, con créditos que crecen a medida que baja el uptime. La tabla de abajo muestra un SLA hipotético con ese formato, con porcentajes redondos elegidos para facilitar la lectura. No son los de ningún proveedor; los valores reales están en la página oficial del SLA.

Fíjate en cuatro detalles que se repiten en casi todos los SLA:

1. El crédito es sobre la factura del servicio afectado (en AWS, la factura del mes de EC2 en la región afectada), no sobre la pérdida que te causó la caída.
2. Tienes que pedirlo. En el caso de AWS, abriendo un caso de soporte con fechas, recursos afectados y logs, antes del final del segundo ciclo de facturación posterior al incidente.
3. Un crédito no es un reembolso. Descuenta cargos futuros.
4. Hay condiciones de arquitectura. El SLA regional de EC2 solo aplica a instancias distribuidas en dos o más zonas de disponibilidad.

Además, los SLA suelen excluir el mantenimiento programado, las fallas causadas por el cliente y los casos de fuerza mayor. Lee siempre la sección de exclusiones antes de comparar dos proveedores.

¿Por qué el uptime de tu app puede ser menor que el del hosting?#

El porcentaje del proveedor mide su propia infraestructura. Tu app depende de más cosas en serie, y la disponibilidad total es el producto de las partes. Un hosting al 99,9%, una base de datos al 99,9% y una API externa al 99,9% dan 0,999 x 0,999 x 0,999, o cerca del 99,7%: casi 2,2 horas al mes.

Varias causas comunes de caída también quedan fuera de cualquier SLA de infraestructura:

• las excepciones no manejadas que terminan el proceso;
• la falta de memoria (el proceso muere por superar su RAM);
• los deploys con reinicio, que tumban la app unos segundos;
• los tokens revocados, los certificados vencidos y los dominios expirados.

Por eso conviene medirlo por tu cuenta. Un monitor externo que prueba la app cada minuto da el número que importa: lo que vio tu usuario. Para bots sin puerto HTTP, mira cómo monitorear el uptime de un bot.

¿Cuánto uptime necesitas de verdad?#

Depende del costo de estar caído, no del número más alto posible:

• 99% (unas 7 h al mes): sirve para un proyecto personal, una herramienta interna o un bot de una comunidad pequeña.
• 99,9% (unos 43 min al mes): un estándar razonable para sitios y APIs comerciales pequeños y medianos.
• 99,99% o más: exige redundancia real, con varias instancias, failover automático y, en general, más de una región. El costo y la complejidad suben mucho. Mira qué es un load balancer para la base de esa arquitectura.

El libro de SRE hace una observación justa: el usuario común no distingue el 99,99% del 99,999% cuando su propio celular y su red son menos confiables que eso. Casi todo proyecto empieza bien servido con el 99,9%.

Si todavía estás eligiendo dónde alojar tu app, compara también el modelo de operación en VPS o plataforma en la nube: en un VPS, los parches, los reinicios y el monitoreo son tarea tuya.

Cómo hacerlo en Square Cloud#

La misma lectura vale en Square Cloud: la disponibilidad es una meta, no una garantía. Las aplicaciones corren en contenedores aislados siempre encendidos, sin cold start ni modo de suspensión, y el reinicio automático (activado por defecto en el deploy desde el panel) vuelve a levantar la aplicación cuando el proceso termina con error. El uptime promedio observado es del 99,99%, un dato histórico, no la promesa de que el servicio nunca se detendrá.

Buena parte del uptime sigue en tus manos: manejar las excepciones, dimensionar la RAM de cada aplicación y seguir los logs y las métricas en tiempo real en el panel. Para la alta disponibilidad de un sitio o una API, el load balancing (desde el plan Standard) reparte un dominio personalizado entre varias aplicaciones, en round-robin con failover pasivo. No hay autoscaling: tú eliges cuántas aplicaciones y cuánta RAM usar.

En el plan Enterprise, un SLA puede discutirse con el equipo. Las funciones de disponibilidad y monitoreo están en la página de funciones.