Monitoreo de sistemas: detecta el error antes que tu cliente

Toda empresa con un sistema en línea ya vivió esta escena. Suena el WhatsApp, es un cliente, y el mensaje dice que el sitio no abre, que el pago no pasa o que la app se traba en el login. Llamas a quien cuida el sistema, y la persona al otro lado también se está enterando ahora.

El problema no es el error. Todo sistema va a fallar en algún momento. El problema es enterarte por el cliente, cuando ya perdió tiempo, ya abandonó la compra o ya se quejó en público. En esta guía muestro qué tiene que medir un monitoreo de verdad, cuánto cuesta no tenerlo y qué pedirle al proveedor que cuida tu producto.

Enterarse de la falla por el cliente sigue siendo común

Parece cosa de empresa pequeña y desorganizada. No lo es. En la encuesta de 2025 de New Relic, hecha con 1.700 profesionales de TI e ingeniería en 23 países, el 41% de los líderes dijo que aún se entera de las caídas por medios ineficientes: quejas de clientes, tickets abiertos o revisión manual.

La misma encuesta muestra lo que esto le hace al equipo. Los ingenieros dedican el 33% de su tiempo a apagar incendios o a lidiar con caídas. Un tercio de lo que pagas en desarrollo se va en perseguir problemas, en lugar de construir lo que el negocio necesita.

Y la demora cuesta. Incluso los equipos con monitoreo completo tardan, en promedio, 28 minutos en detectar una caída, según New Relic. Los demás tardan 7 minutos más. En un sistema que vende, agenda o atiende, cada uno de esos minutos tiene un cliente al otro lado.

Cuánto cuesta una caída

Las cifras de las encuestas globales son de empresas grandes, pero la proporción vale para cualquier tamaño. El informe anual de caídas del Uptime Institute, publicado en mayo de 2026, muestra que el 57% de las empresas dijo que su última gran caída costó más de US$ 100 mil. Por segundo año seguido, una de cada cinco superó US$ 1 millón.

El mismo informe trae un dato que importa si tu sistema está en la nube. En nueve años de caídas registradas públicamente, cerca de dos tercios vinieron de proveedores externos: nube, internet, telecomunicaciones y data centers alquilados. New Relic apunta en la misma dirección. Las tres causas más comunes de caídas graves son fallas de red, fallas del proveedor de nube o de un servicio externo, y la publicación de código nuevo.

Llevado a tu caso: buena parte de lo que va a romper tu sistema no está en el código que pagaste. Está en la pasarela de pago, en el envío de correos, en el servicio de login, en el hosting. Y la otra parte viene de la propia actualización que tu equipo publicó el viernes por la tarde. Monitorear es cubrir las dos.

Qué medir: las cuatro señales básicas

Google publicó en su libro de ingeniería de confiabilidad, Site Reliability Engineering, cuatro señales que todo sistema orientado al usuario debería medir. En lenguaje de negocio:

1. Tiempo de respuesta. Cuánto tarda el sistema en responder. Una página que abre en 8 segundos está en línea, pero el cliente ya se fue.
2. Volumen de uso. Cuántas personas o solicitudes recibe el sistema. Una caída repentina de visitas a las 10 de la mañana de un martes es señal de problema, aunque no haya ningún error visible.
3. Errores. La proporción de solicitudes que fallan. Incluye el error que aparece en pantalla y el que no, como un registro que parece guardado y no lo está.
4. Saturación. Qué tan cerca está el sistema de su límite: disco, memoria, base de datos, cuota de un servicio externo. Es la señal que avisa antes de que se rompa.

El mismo libro resume la función de todo esto en una frase: el monitoreo existe para que el sistema “nos diga cuándo está roto, o quizá qué está a punto de romperse”. Y trae una regla que vale oro para quien paga la cuenta: toda alerta debe exigir una acción. Una alerta que nadie necesita resolver se vuelve ruido, y el ruido hace que el equipo ignore la alerta que importa.

Lo que las cuatro señales no detectan

Hay un tipo de falla que ninguno de estos gráficos muestra: el sistema en línea, rápido, sin errores y con el dato equivocado. El informe suma el doble. El inventario queda en negativo. El descuento se aplica dos veces. La agenda acepta dos clientes en el mismo horario.

Es el error más caro, porque tarda en aparecer. Cuando alguien lo nota, ya son semanas de números equivocados en decisiones de negocio. Para detectar este tipo de falla, el monitoreo también tiene que mirar los datos: totales que no cuadran, registros fuera del patrón, procesos que debían ejecutarse y no lo hicieron.

Por eso separo el monitoreo en tres capas:

• ¿Está en línea? Verificación de afuera hacia adentro, cada pocos minutos, en las páginas y rutas que más importan: inicio, login, pago, formulario de contacto.
• ¿Está funcionando? Tiempo de respuesta, tasa de error y saturación, desde dentro del sistema, con registro de cada falla.
• ¿Está bien? Revisión de los datos y de los procesos que hacen avanzar el negocio.

Muchos sistemas en línea solo tienen la primera capa. Avisa cuando todo se cae, pero no cuando el sistema funciona mal.

Qué pedirle al proveedor que cuida tu sistema

El monitoreo no es una herramienta que compras y enciendes. Es una rutina con responsable. Antes de firmar o renovar un contrato de mantenimiento, revisa que responda por escrito a estas preguntas:

• Qué se verifica y con qué frecuencia. Qué páginas, qué rutas, qué procesos. “Todo el sistema” no es una respuesta.
• Quién recibe la alerta. Una persona con nombre, no un correo que nadie lee.
• En cuánto tiempo alguien empieza a resolver. Según la gravedad: un pago detenido no espera al lunes.
• Cómo te enteras tú. La alerta técnica va a quien corrige. Tú recibes qué pasó, cuánto duró, a quién afectó y qué se hizo.
• Qué incluye el informe mensual. Disponibilidad, errores más frecuentes, tiempo de respuesta y lo que se mejoró.
• A nombre de quién están las cuentas. Las herramientas de monitoreo y el historial de alertas también son parte de tu sistema.

Si estás armando ese presupuesto ahora, escribí sobre cuánto cuesta mantener un sistema o app en línea, con las partidas que el monitoreo necesita. Y si el producto se hizo con herramientas de IA, el riesgo de errores silenciosos suele ser mayor. Expliqué por qué en el costo de mantenimiento del vibe coding.

Cómo lo hacemos en el Studio

En el Studio, todo sistema que entregamos sale con un agente de IA que se ejecuta todos los días. Señala fallas, sugiere mejoras y revisa que los datos tengan sentido. Es la tercera capa, la del “¿está bien?”, que casi nadie cubre y que suele ser la más cara cuando falla.

El resto sigue el mismo principio que usamos en el proyecto. Precio cerrado después del diagnóstico y plazo por escrito en el contrato. El código, los archivos y los accesos quedan a nombre del cliente, incluidas las cuentas de las herramientas. Nuestro equipo de desarrollo es propio, y usamos Claude Code y Figma en el diseño y el desarrollo.

Menos piezas también significa menos lugares donde una falla puede esconderse. En LCX, empresa de turismo con operación en más de 10 países de América del Sur, un sistema por país se convirtió en uno solo, en línea en 29 días. Un sistema que monitorear, en lugar de uno por país.

Si hoy quien te avisa que tu sistema se cayó es el cliente, ese es el primer trabajo de nuestro servicio de mantenimiento y evolución de sistemas: poner a alguien, y algo, vigilando antes que él.