# El tiempo entre que algo falla y que alguien se entera > El gap de detección es la fase que casi nadie mide: qué tarda un equipo en saber que hay un problema y cómo acortarlo antes de pensar en la respuesta. - Autor: José Manuel García Locubiche - Publicado: 2026-09-07 - Actualizado: 2026-09-25 - Original: https://jose-m.net/2026/blog/tech/el-tiempo-entre-que-algo-falla-y-que-alguien-se-entera/ ---
## El problema que no está en el dashboard La mayoría de las empresas invierten en gestión de incidentes pensando en la fase de respuesta: on-call bien entrenado, protocolos de comunicación, runbooks, postmortems estructurados. Todo eso importa. Pero hay una fase anterior que casi nunca se mide ni se gestiona con la misma disciplina: el tiempo que transcurre entre que algo empieza a romperse y el momento en que alguien, humano o sistema, se da cuenta. A ese hueco lo llaman el **gap de detección**, y durante ese tiempo, el daño se sigue acumulando sin que nadie mueva un dedo, simplemente porque nadie sabe que hay que moverlo. ## Por qué la monitorización automática no es suficiente La monitorización automática solo detecta lo que alguien pensó en programar. Es una herramienta poderosa, pero tiene un límite: no puede alertar sobre un fallo que nadie anticipó al diseñar las métricas y umbrales. Por eso la detección humana sigue siendo insustituible: soporte, ventas, éxito de cliente, redes sociales, e incluso empleados que usan el propio producto internamente. Un ejemplo interesante es el de equipos que monitorizan el tráfico de su propia página de estado pública como señal indirecta: si mucha gente entra a comprobar el estado del servicio, probablemente algo ya está mal, aunque las métricas internas todavía no lo reflejen. ## Bajar la barrera para reportar un problema Cuando reportar un problema significa automáticamente declarar un incidente formal —con on-call, canal dedicado, protocolo completo—, la gente se lo piensa dos veces antes de hacerlo. Nadie quiere ser quien active toda esa maquinaria por algo que quizá no sea grave, así que muchas señales tempranas se quedan sin reportar. La solución es tener un canal ligero, de baja fricción, para decir simplemente "creo que algo puede estar mal", sin que eso dispare automáticamente todo el proceso formal. Quien reporta no necesita diagnosticar el problema ni saber qué tipo de respuesta hace falta: basta con describir lo que ha visto. Después, alguien con más contexto puede valorar si eso hay que escalarlo a incidente completo o si con una revisión rápida es suficiente. Pero ese canal solo funciona si alguien lo mira de forma activa, no si depende de que la gente vaya a consultarlo cuando ya sospecha algo grave. Sin revisión proactiva, se convierte en un buzón muerto: se reporta, pero nadie lee esos reportes hasta que el problema ya ha escalado por otra vía. Basta con que alguien de guardia lo revise por rutina, igual que revisa un dashboard, o con vigilar el volumen de reportes como señal en sí misma: si normalmente hay uno al día y de repente hay cinco en una hora, eso ya dice algo, aunque cada reporte individual parezca menor. Cuanto más fácil sea reportar una sospecha y más activamente se vigile ese canal, antes llegan las señales que permiten cerrar el gap de detección. ## El alerting necesita mantenimiento continuo Bajar umbrales o añadir alertas sin criterio parece una mejora, pero genera fatiga de alertas. Y la fatiga de alertas erosiona la confianza del on-call poco a poco, hasta que las alertas reales terminan perdidas en el ruido de las que no aportan nada. La recomendación aquí es simple pero exige disciplina: podar regularmente las alertas que no generan valor, igual que se hace con la deuda técnica. Hace unas semanas escribí sobre [qué parte de ese trabajo puede hacer un modelo por su cuenta y qué parte no](/2026/blog/tech/ia-en-operaciones-donde-si-y-donde-no/). ## Una pregunta que falta en la mayoría de postmortems Cuando ocurre un incidente, casi todos los postmortems se centran en qué pasó y cómo se resolvió. Pocos se detienen a preguntar específicamente: - ¿Cuánto duró el gap de detección? - ¿Se pudo haber detectado antes? - ¿Qué monitoreo o umbral habría marcado la diferencia? Incorporar esta pregunta de forma sistemática convierte cada incidente en una oportunidad concreta para reducir el próximo gap, en lugar de limitarse a mejorar la respuesta. ## Conclusión Toda la inversión en respuesta a incidentes pierde buena parte de su valor si antes no se sabe que hay un problema. Detectar rápido no es glamuroso ni suele aparecer en las métricas que se presentan a dirección, pero es la base sobre la que se sostiene todo lo demás.