PathSeptiembre de 2026
Cuando el monitoreo se come el mantenimiento: falsos positivos y escenarios
Una agencia nos contactó porque su monitoreo creaba más trabajo del que evitaba. Demasiadas alertas sin impacto, demasiados retoques de escenarios en tech.
El tema real no era «otra herramienta»
No buscaban una sonda más. Querían salir de un bucle: un cambio menor en un sitio cliente, una alerta, un ticket interno, un desarrollador que reabre el escenario, lo corrige y lo vuelve a probar. Los jefes de proyecto esperaban.
En un parque de unos cuarenta sitios en mantenimiento, el coste no era teórico. Quince a veinte alertas por semana, una buena mitad sin avería real. Treinta a cuarenta y cinco minutos por retoque. Seis a ocho horas de tech por semana solo para mantener vivos los escenarios.
Lo que rompía de verdad el modelo
Un monitoreo de recorridos útil se vuelve pronto inutilizable si solo pueden mantenerlo quienes saben leer un selector. El mantenimiento es un oficio de seguimiento al cliente. Si cada microcambio de interfaz exige un desarrollador, ya no vigila: cuida alertas.
Lo que pusieron en marcha
Los escenarios críticos (login, contacto, recorridos de negocio) siguen siendo recorridos de navegador desde Europa, con captura cuando un paso falla. La diferencia no es mágica: es quién puede —y sabe— hacerlos evolucionar.
Los jefes de proyecto actualizan los escenarios de los sitios que gestionan. Tech entra cuando algo se rompe de verdad, no por cada variación de UI. En la práctica: unos tres veces menos falsos positivos, y media jornada tech recuperada cada semana en el mantenimiento.
Lo que mantenemos, lo que no prometemos
No prometemos cero alertas. Un recorrido que cambia a menudo seguirá pidiendo algo de atención. Sobre todo prometemos que esa atención puede vivir en el sitio correcto: en proyecto, cerca del cliente, sin convertir cada banner de cookies en un incidente de equipo. Montar escenarios debe ser simple. La infraestructura, invisible.
Tres preguntas en una revisión de mantenimiento
- ¿Cuántas alertas de la semana pasada tuvieron impacto real en el cliente?
- ¿Quién corrigió el último escenario roto: un jefe de proyecto o un desarrollador?
- ¿Cuántas horas tech siguen yéndose a cuidar el monitoreo en lugar de entregar o corregir sitios?
Si la respuesta a la segunda pregunta es siempre «un desarrollador», el monitoreo probablemente cuesta más de lo que protege. La página de agencias describe cómo montamos los escenarios de forma simple y de qué nos ocupamos después.