Calculadora de disponibilidad (uptime)
Introduce un porcentaje de disponibilidad para ver exactamente cuánta caída permite, o introduce una incidencia que ya hayas tenido para ver qué nivel de SLA sigue cumpliendo.
Disponibilidad → caída permitida
- Al año
- 8 h 45 min 36 s
- Al mes
- 43 min 12 s
- A la semana
- 10 min 5 s
- Al día
- 1 min 26 s
Incidencia → disponibilidad alcanzada
Disponibilidad alcanzada
99,444%
Eso todavía cumple un compromiso del 99 %.
That outage breached a standard SLA level
A single slow recovery can consume an entire period's downtime budget, however well the rest of it ran. If that is a pattern rather than a one-off, the fix is usually architectural — and it is what we do.
¿Qué significa realmente un porcentaje de disponibilidad?
Un porcentaje de disponibilidad es una promesa sobre la proporción de una ventana de medición durante la cual un servicio estará accesible. Una disponibilidad del 99,9 % significa que el servicio puede estar caído una décima parte del uno por ciento de la ventana, algo que suena insignificante hasta que se convierte en tiempo real y se descubre que permite 43 minutos de caída cada mes.
El porcentaje por sí solo carece casi de sentido sin tres datos adicionales: la duración de la ventana de medición, qué cuenta como caída y quién la mide. Un compromiso del 99,9 % medido anualmente tolera una única caída de ocho horas; ese mismo 99,9 % medido mensualmente, no. Ese es el detalle sobre el que giran la mayoría de las disputas de SLA, y casi siempre está enterrado en un apartado de definiciones en lugar de figurar junto a la cifra.
Cómo se calcula la caída permitida
La aritmética es sencilla, y conviene verla en lugar de darla por buena: la caída permitida es exactamente la parte de la ventana que el compromiso deja sin cubrir.
-
Resta el porcentaje de disponibilidad a 100 para obtener la indisponibilidad permitida. Para el 99,9 %, eso es 0,1 %.
-
Exprésalo como fracción: 0,1 % pasa a ser 0,001.
-
Multiplícalo por la duración de la ventana de medición en segundos. Un mes de 30 días son 2.592.000 segundos, así que 0,001 × 2.592.000 = 2.592 segundos.
-
Reconviértelo a unidades legibles: 2.592 segundos son 43 minutos y 12 segundos.
Esta calculadora usa un año de 365 días y un mes de 30 días, la convención que emplea cada gran proveedor cloud en su propio SLA. Importa más de lo que parece: usar un año de 365,25 días desplazaría la cifra del 99,999 % en unos ocho segundos, y cualquiera que comparase esta página con la tabla de SLA de AWS o Azure encontraría una discrepancia y no se fiaría de ninguna de las dos.
Tabla de referencia: disponibilidad y tiempo de caída
Los niveles estándar, convertidos. La mayoría de los SLA comerciales se sitúan entre el 99,5 % y el 99,99 %; la fila de los cinco nueves aparece sobre todo porque se cita mucho más de lo que se contrata.
| Disponibilidad | Al año | Al mes | A la semana | Al día |
|---|---|---|---|---|
| 90% | 36d 12h | 3d | 16h 48m | 2h 24m |
| 95% | 18d 6h | 1d 12h | 8h 24m | 1h 12m |
| 99% | 3d 15h 36m | 7h 12m | 1h 40m 48s | 14m 24s |
| 99.5% | 1d 19h 48m | 3h 36m | 50m 24s | 7m 12s |
| 99.9% | 8h 45m 36s | 43m 12s | 10m 5s | 1m 26s |
| 99.95% | 4h 22m 48s | 21m 36s | 5m 2s | 43s |
| 99.99% | 52m 34s | 4m 19s | 1m | 9s |
| 99.999% | 5m 15s | 26s | 6s | 1s |
Basado en un año de 365 días y un mes de 30 días, según la convención de los SLA publicados por los proveedores cloud.
Por qué cada nueve adicional cuesta mucho más
Cada nueve adicional reduce diez veces la caída permitida, y el coste de conseguirlo no baja ni de lejos con la misma elegancia. La distancia entre el 99 % y el 99,9 % es sobre todo cuestión de una operación competente. La distancia entre el 99,9 % y el 99,99 % suele ser un cambio arquitectónico: redundancia entre zonas de disponibilidad, conmutación automática por error y la eliminación de cada punto único de fallo que llevas tiempo tolerando.
El último nueve es con el que hay que tener cuidado. Pasar del 99,99 % al 99,999 % deja unos cinco minutos de caída al año: menos que un solo reinicio no planificado y menos de lo que consumen la mayoría de los procesos de despliegue. Comprometerse a ello implica que toda operación de mantenimiento rutinario debe hacerse sin interrupción, y eso es una propiedad de la arquitectura, no algo que un equipo de operaciones pueda prometer a base de diligencia.
¿Qué porcentaje de disponibilidad conviene comprometer?
El nivel adecuado es aquel en el que el coste del siguiente nueve supera el coste de la caída que evita. Para un sistema interno de informes usado en horario laboral, el 99 % suele ser perfectamente razonable y nadie nota la diferencia. Para una pasarela de pago o un proceso de compra, una hora de caída puede costar más que un año entero de la infraestructura necesaria para evitarla.
Un enfoque práctico es razonar hacia atrás desde la consecuencia en lugar de hacia delante desde la ambición. Calcula lo que cuesta de verdad una hora de indisponibilidad —transacciones perdidas, personal parado, carga de soporte, penalizaciones contractuales— y compáralo con la inversión de ingeniería que exige cada nueve adicional. Comprometerse públicamente con un nivel para el que no has diseñado la arquitectura es peor que comprometerse honestamente con uno inferior, porque la primera caída convierte un problema de ingeniería en uno contractual.
Cómo mejorar la disponibilidad
Mejorar la disponibilidad consiste sobre todo en eliminar puntos únicos de fallo y en acortar el tiempo que se tarda en detectar los fallos restantes y recuperarse de ellos. Aproximadamente por orden de retorno sobre el esfuerzo:
- Mide con honestidad primero. Si no puedes decir cuál fue tu disponibilidad el trimestre pasado, cualquier objetivo es una aspiración. Las comprobaciones sintéticas desde fuera de tu red son el mínimo: detectan las caídas que tu monitorización interna no ve porque está dentro del fallo.
- Elimina los puntos únicos de fallo que ya conoces. La mayoría de los equipos sabe nombrarlos: el único servidor de base de datos, el paso manual de conmutación, el certificado que alguien renueva a mano.
- Acorta el tiempo de detección. El tiempo de recuperación suele estar dominado por el tiempo hasta darse cuenta, no por el tiempo de arreglo, y alertar sobre síntomas que sienten los usuarios es mejor que alertar sobre métricas de servidor.
- Haz que el mantenimiento rutinario no interrumpa. Cuando despliegues, migraciones y parches requieren todos una parada, tu mantenimiento planificado compite con tu SLA por el mismo presupuesto de minutos.
La redundancia merece añadirse después de todo eso, no antes. Una infraestructura redundante que conmuta despacio, o que nunca se ha probado ante un fallo real, tiende a convertir caídas cortas en largas en lugar de evitarlas.
Ejemplo resuelto: un SLA mensual del 99,9 %
Supongamos que te has comprometido a un 99,9 % de disponibilidad medido mensualmente, y que una conmutación de base de datos tardó cuatro horas un martes por la tarde.
43m 12s
Al mes
Un compromiso mensual del 99,9 % permite 43m 12s de caída. Una incidencia de cuatro horas es unas cinco veces y media ese margen, lo que deja el mes en torno al 99,44 %: cumple el 99 %, pero incumple el 99,9 %.
Fíjate en lo que eso implica para el resto de la ventana: una sola incidencia de cuatro horas agota por completo el presupuesto mensual, de modo que el SLA se incumple por impecables que fueran los otros 27 días. Esa asimetría explica por qué el trabajo de disponibilidad se concentra en el tiempo de recuperación y no en la frecuencia de los fallos: una recuperación lenta cuesta más que varias rápidas.
Common questions
¿Qué significa realmente un porcentaje de disponibilidad?
Un porcentaje de disponibilidad es una promesa sobre la proporción de una ventana de medición durante la cual un servicio estará accesible. Una disponibilidad del 99,9 % significa que el servicio puede estar caído una décima parte del uno por ciento de la ventana, algo que suena insignificante hasta que se convierte en tiempo real y se descubre que permite 43 minutos de caída cada mes.
Cómo se calcula la caída permitida
La aritmética es sencilla, y conviene verla en lugar de darla por buena: la caída permitida es exactamente la parte de la ventana que el compromiso deja sin cubrir.
¿Qué porcentaje de disponibilidad conviene comprometer?
El nivel adecuado es aquel en el que el coste del siguiente nueve supera el coste de la caída que evita. Para un sistema interno de informes usado en horario laboral, el 99 % suele ser perfectamente razonable y nadie nota la diferencia. Para una pasarela de pago o un proceso de compra, una hora de caída puede costar más que un año entero de la infraestructura necesaria para evitarla.
Cómo mejorar la disponibilidad
Mejorar la disponibilidad consiste sobre todo en eliminar puntos únicos de fallo y en acortar el tiempo que se tarda en detectar los fallos restantes y recuperarse de ellos. Aproximadamente por orden de retorno sobre el esfuerzo:
Lecturas relacionadas
Cloud Cost Optimization Strategies: 10 Actionable Tactics
Explore 10 actionable cloud cost optimization strategies for mid-market and enterprise teams, covering rightsizing, autoscaling, FinOps, and observability.
What Is Infrastructure as Code: A Complete Guide for 2026
Learn what is infrastructure as code, how declarative and imperative approaches differ, and how to adopt IaC without losing control in 2026.
Business Continuity Best Practices: A 2026 Guide
Explore 10 business continuity best practices for software platforms. Learn to build resilient systems with tips on RTO/RPO, IaC, DR testing, and SRE.
¿Comprometido con una cifra para la que no has diseñado?
Ryware diseña y opera sistemas de alta disponibilidad para organizaciones donde la caída se mide en ingresos perdidos y no en molestias: redundancia probada ante fallos reales, conmutación que se completa sin una persona en el bucle y monitorización que se entera antes que tus clientes.