El MTTR (mean time to recovery o repair, tiempo medio de recuperación o reparación) es el tiempo medio desde que empieza una incidencia hasta que el servicio vuelve a funcionar. El MTTA (mean time to acknowledge, tiempo medio de reconocimiento) es el tiempo medio desde una alerta hasta que alguien confirma que se está ocupando de ella. El MTBF (mean time between failures, tiempo medio entre fallos) es el tiempo medio que un servicio funciona con normalidad entre incidencias. Juntos describen la fiabilidad: el MTBF indica cada cuánto se rompe algo, el MTTA lo rápido que respondes y el MTTR cuánto tiempo se ven afectados tus clientes.
Esta guía repasa las definiciones, las fórmulas, un ejemplo con números, qué marcas de tiempo hay que recoger y los cambios prácticos que mejoran cada métrica.
Las métricas y qué miden
MTTR: cuatro significados, un solo acrónimo
El MTTR es la métrica de incidencias más citada y la más confusa, porque la R significa cosas distintas según quién la use:
Mean time to repair (tiempo medio de reparación): desde que empieza el trabajo de reparación hasta que la solución está aplicada. Habitual en hardware y mantenimiento.
Mean time to recovery o restore (tiempo medio de recuperación): desde que empieza la caída hasta que el servicio vuelve a funcionar para los usuarios. La versión más útil para webs y API.
Mean time to respond (tiempo medio de respuesta): desde la alerta hasta que el equipo empieza a actuar. Muy parecido al MTTA.
Mean time to resolve (tiempo medio de resolución): hasta que la incidencia queda cerrada del todo, incluido el seguimiento que evita que se repita.
Ninguna es incorrecta. Lo importante es elegir una, dejar la definición por escrito y usarla siempre igual. Comparar tu cifra de «recuperación» con la de «reparación» de otro no te dice nada. En este artículo, MTTR significa tiempo medio de recuperación: desde que el servicio se rompió hasta que volvió a funcionar.
MTTD y MTTA: la respuesta antes de la reparación
El MTTD (mean time to detect, tiempo medio de detección) es el tiempo desde que empieza una incidencia hasta que la monitorización lanza una alerta. El MTTA es el tiempo desde esa alerta hasta que una persona la reconoce. Ambos forman parte del MTTR, y por eso importan tanto: nadie puede arreglar un problema del que no se ha enterado.
MTBF: cada cuánto se rompe algo
El MTBF es el tiempo medio de funcionamiento entre incidencias. Cuanto más alto, mejor. Su pariente, el MTTF (mean time to failure, tiempo medio hasta el fallo), se usa para cosas que se sustituyen en lugar de repararse, como los discos; para servicios online, el que necesitas es el MTBF.
Las fórmulas
MTTD = tiempo total desde el inicio de la incidencia hasta la alerta / número de incidencias
MTTA = tiempo total desde la alerta hasta el reconocimiento / número de incidencias
MTTR = tiempo total desde el inicio de la incidencia hasta la recuperación / número de incidencias
MTBF = tiempo total de funcionamiento sin incidencias / número de incidencias
Disponibilidad = MTBF / (MTBF + MTTR)
La última línea muestra por qué importan los dos lados. Puedes mejorar la disponibilidad teniendo menos incidencias (un MTBF más alto) o haciéndolas más cortas (un MTTR más bajo). Acortarlas suele salir mucho más barato.
Un ejemplo con números
Este es un mes de ejemplo para una tienda online, con cuatro incidencias. Las cifras son inventadas para ilustrar el cálculo, pero las marcas de tiempo son las que te da cualquier herramienta de monitorización.
IncidenciaInicioAlertaReconocidaRecuperadaDetecciónReconocimientoRecuperaciónCheckout con 50303:1203:1303:1603:191 min3 min7 minTimeouts en la API10:0510:0610:0810:411 min2 min36 minErrores de inicio de sesión14:3014:3114:4515:021 min14 min32 minBúsqueda caída22:5022:5122:5623:151 min5 min25 min
Ahora aplica las fórmulas:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minuto.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minutos.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minutos.
MTBF: un mes de 30 días tiene 43.200 minutos. Si restas 100 minutos de caída, quedan 43.100. Divididos entre 4 incidencias, el MTBF es de 10.775 minutos, unos 7,5 días.
Disponibilidad = 10.775 / (10.775 + 25) = 99,77 %.
Destacan dos cosas. Los 14 minutos de reconocimiento en la incidencia de inicio de sesión suben el MTTA de unos 3 minutos a 6, así que merece la pena preguntarse por qué nadie atendió esa alerta. Y con un 99,77 %, esta tienda se queda bastante lejos de un objetivo del 99,9 %, que solo permite 43 minutos al mes. Si estás fijando objetivos así, lee SLA vs SLO vs SLI para ver cómo encajan.
Imagina ahora el mismo mes con comprobaciones cada cinco minutos y sin paso de confirmación. La detección podría tardar hasta cinco minutos en lugar de uno, lo que añade hasta cuatro minutos a cada incidencia. El MTTR sube de 25 a hasta 29 minutos sin que nadie haya hecho nada distinto.
Qué marcas de tiempo recoger
Necesitas cuatro marcas de tiempo por incidencia. La mayoría salen directamente de la monitorización:
Inicio: la primera comprobación fallida. La monitorización externa la registra aunque tus servidores no registren nada.
Alerta: cuándo se confirmó el fallo y se envió la notificación.
Reconocimiento: cuándo una persona dijo «me encargo yo». Si no tienes herramienta de guardias, sirve una respuesta en el canal de incidencias; apunta la hora. En Uptimecheck reconoces la incidencia en la app o, con la app de Slack, con un botón en Slack, y la hora queda registrada.
Recuperación: la primera comprobación correcta después de la incidencia, que es también cuando se envía el aviso de recuperación.
Con Uptimecheck, cada incidencia tiene una cronología: cuándo empezó, a quién se avisó y cuándo, los reconocimientos (también con un botón en Slack si usas la app de Slack), las notas y la recuperación. El MTTA y el MTTR se calculan solos, y la exportación CSV del informe te da, para una hoja de cálculo, el número de incidencias, el tiempo de caída y la incidencia más larga de cada monitor. Añade lo que hayas aprendido en un postmortem.
Una advertencia práctica: las medias esconden los valores atípicos. Una incidencia de seis horas y nueve cortes de un minuto dan una media de unos 37 minutos, que no describe ninguno de los dos casos. Mira la mediana y la incidencia más larga junto a la media, y revisa una a una las incidencias más lentas.
Cómo reducir el tiempo de detección
Comprueba cada minuto
El intervalo de comprobación es el límite máximo de tu tiempo de detección. Comprobar cada minuto todo lo que genera ingresos o atiende a clientes es la mejora más barata del MTTR. Usa la monitorización de uptime cada minuto en todas las páginas y endpoints críticos.
Comprueba lo que falla, no solo lo que carga
Las incidencias que la monitorización no ve las detectan los clientes, a menudo horas después. Valida el contenido de las páginas importantes, monitoriza los endpoints de la API de los que dependen las apps y añade heartbeats a las tareas programadas. Cada incidencia que un cliente notifica primero es un hueco en tu monitorización.
Cómo reducir el tiempo de reconocimiento
Envía solo alertas confirmadas
Un reconocimiento lento suele ser un problema de confianza. Si la mitad de las alertas son falsas, la gente aprende a esperar a ver qué pasa. Confirma cada fallo con una segunda comprobación antes de alertar y elimina los monitores que alertan sin que nadie tenga que hacer nada. Nuestra guía para reducir las falsas alertas explica los detalles.
Envía las alertas al canal adecuado
Un email a las 03:12 se leerá a las 07:30. Envía los monitores críticos a un canal que llegue al móvil de la persona de guardia y a un chat de equipo para los demás, y deja los monitores menos urgentes en el email. Uptimecheck te permite elegir los canales de alerta de cada monitor: email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks y notificaciones push en el móvil, en todos los planes. El escalado puede retener un canal entre 5 y 60 minutos y avisar solo si la caída continúa y nadie la ha reconocido.
Deja clara la responsabilidad
Una alerta enviada a cinco personas a menudo no la reconoce ninguna. Nombra un responsable por servicio y una persona de guardia por turno. Los demás reciben la información, no la responsabilidad. Con los turnos de guardia de Uptimecheck, las personas se van turnando, con excepciones para un día de baja o un cambio de turno, y las alertas push llegan a quien esté de guardia en ese momento.
Cómo reducir el tiempo de reparación
Escribe runbooks para los fallos conocidos
La mayoría de las incidencias se repiten. El disco se llena, se agota un pool de workers, falla la renovación de un certificado. Un runbook breve por monitor convierte una investigación medio dormido en una lista de comprobación:
Runbook: el checkout devuelve 503
1. Revisa el panel del servidor: CPU, memoria y disco en web-01 y web-02.
2. Comprueba el estado de PHP-FPM: sudo systemctl status php8.3-fpm
3. Si los workers están agotados: sudo systemctl restart php8.3-fpm
4. Busca procesos de larga duración: ps aux –sort=-%cpu | head
5. ¿Sigue fallando tras 10 minutos? Escala al desarrollador principal.
Ten el enlace al runbook donde llega la alerta, por ejemplo fijado en el canal de incidencias, para que esté a un toque.
Pon la causa y el síntoma uno al lado del otro
Cuando falla la comprobación de una web, la primera pregunta suele ser si el servidor se ha quedado sin memoria, CPU o disco. Tener las métricas del servidor junto a las comprobaciones de uptime reduce ese paso de una sesión SSH a un vistazo.
Que revertir sea fácil
Muchas incidencias empiezan con un despliegue. Si revertir es un solo comando, la recuperación lleva minutos. Si hace falta una reunión, lleva una hora.
Actualiza pronto la página de estado
Una página de estado no acorta la caída en sí, pero sí la parte que peor llevan los clientes: no saber qué pasa. Además, evita que soporte se vea desbordado mientras el equipo soluciona el problema. Una página de estado conectada a tus monitores muestra el componente afectado en cuanto se abre la incidencia; añade una nota breve sobre lo que estás haciendo y cuándo darás la próxima actualización.
Cómo mejorar el MTBF
Tener menos incidencias pasa por aprender de las que ya has tenido. Después de cada incidencia importante, escribe un postmortem sin culpables, acuerda una o dos acciones y haz su seguimiento hasta que estén hechas. En pocos meses, los mismos fallos dejan de repetirse y el MTBF sube.
Empieza a medir con marcas de tiempo reales. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.