Las dos direcciones comparten una sola fórmula. Si partes de un porcentaje de SLA obtienes la inactividad que permite (eso es nuestra calculadora de disponibilidad). Si partes de la inactividad que tuviste, como hace esta página, obtienes el porcentaje de disponibilidad que produjo: (ventana − inactividad) ÷ ventana × 100. Añadimos los dos datos que una hoja de cálculo no te da: lo que costó y adónde fueron los minutos.

Divide la inactividad entre la ventana y multiplica por 100. Una caída de 43m 48s en un mes de 30,42 días: 2.628 s ÷ 2.628.000 s × 100 = 0,1 % de inactividad — es decir, 99,9 % de disponibilidad. Dos reglas: suma todos los incidentes de la ventana (no los promedies) y mide desde la primera solicitud fallida hasta la recuperación verificada.

Entre dos y tres nueves es la banda habitual para servicios de producción pequeños y medianos — de 43 minutos a 7 horas al mes. Tres nueves (43m 48s al mes) es el objetivo de referencia: alcanzable con buen hosting, rollbacks rápidos y alguien de guardia. Si tu mes supera las 7 horas, la tabla de daños de arriba muestra la calificación que estás dando — y la sección de cronología del resultado muestra por dónde recortar minutos primero.

Olvídate de las cifras por minuto de los estudios corporativos — promedian bancos con panaderías. Tu techo es tu propia aritmética: ingresos por hora × horas caído, más las personas que lo dejaron todo, más cualquier cláusula contractual. La sección de coste del resultado lo calcula en vivo con tus cifras. Dos matices. Algunos compradores interrumpidos vuelven más tarde, así que los ingresos perdidos son un techo. Y algunos costes no caben en ninguna hoja de cálculo: la confianza, el SEO, el backlog de soporte.

Cuentan como decidiste que contaran — antes del incidente. Práctica habitual: una ruta crítica rota (el pago, el inicio de sesión) cuenta por completo aunque la portada se cargue; lo degradado-pero-funcional cuenta aparte o no cuenta. Escribe la definición y aplícala siempre igual. Las discusiones de SLA son sobre este párrafo, no sobre la aritmética.

MTTR es el tiempo medio de recuperación: inactividad total ÷ número de incidentes. Es tu mejor palanca, porque reducirlo a la mitad reduce a la mitad tu inactividad sin evitar ni un solo incidente. MTBF es el tiempo medio entre fallos, o con qué frecuencia se rompen las cosas. Depende de la arquitectura y la disciplina de cambios, no de la velocidad de respuesta. Juntos dan la disponibilidad: MTBF ÷ (MTBF + MTTR). RTO es el MTTR que prometiste — cuánto puede durar una caída antes de que el plan de recuperación haya fallado. Pruébalo antes de que lo haga un incidente.

Ataca primero el MTTR y después el MTBF — recuperarte más rápido sale más barato que fallar menos. Y dentro del MTTR, ataca primero la detección: es la única fase que una herramienta puede recortar de raíz. En nuestro ejemplo resuelto, la detección tardó 11 minutos y el arreglo, 4. Las comprobaciones cada treinta segundos limitan el silencio previo al primer fallo detectado a medio minuto — no pueden acortar el envío de la alerta ni el tiempo que tarda alguien en coger el teléfono, por eso aquí la detección se reduce en cuatro minutos, no en once. El diagnóstico se acorta con evidencia (resultados desde varias ubicaciones, marcas de tiempo exactas); el arreglo en sí se acorta con rollbacks ensayados — esa parte depende de ti.

No puedes calcular lo que no notaste — el reinicio de las 3 de la madrugada de nuestro registro de junio solo existe porque algo lo estaba vigilando. La monitorización independiente te da los datos que necesita esta calculadora: horas exactas de inicio y fin, desde fuera de tu propia infraestructura. Eso cubre todos los incidentes, incluidos los que ocurrieron mientras nadie estaba despierto. Uptimia comprueba desde más de 171 ubicaciones en más de 70 países — cada 60 segundos en el plan Basic, cada 30 desde Professional — y guarda ese registro por ti.