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

Divida la inactividad entre la ventana y multiplique 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: sume todos los incidentes de la ventana (no los promedie) y mida 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 su mes supera las 7 horas, la tabla de daños de arriba muestra la calificación que está dando — y la sección de cronología del resultado muestra por dónde recortar minutos primero.

Olvídese de las cifras por minuto de los estudios corporativos — promedian bancos con panaderías. Su techo es su 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 costo del resultado lo calcula en vivo con sus cifras. Dos matices. Algunos compradores interrumpidos vuelven más tarde, así que los ingresos perdidos son un techo. Y algunos costos no caben en ninguna hoja de cálculo: la confianza, el SEO, el backlog de soporte.

Cuentan como decidió 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. Escriba la definición y aplíquela 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 su mejor palanca, porque reducirlo a la mitad reduce a la mitad su 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 prometió — cuánto puede durar una caída antes de que el plan de recuperación haya fallado. Pruébelo antes de que lo haga un incidente.

Ataque primero el MTTR y después el MTBF — recuperarse más rápido sale más barato que fallar menos. Y dentro del MTTR, ataque 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 contestar 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 usted.

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