PathAbril de 2026
Un HTTP 200 no prueba que un cliente pueda pagar
La monitorización está en verde, la página de inicio responde en doscientos milisegundos y, sin embargo, nadie ha comprado desde el martes. De ahí nació Pathly.
Qué mira realmente una sonda HTTP
Una sonda HTTP abre una dirección, lee el código de respuesta y cierra. Si el servidor responde 200, concluye que todo va bien. Es cierto, y es muy insuficiente: no ha pulsado nada, no ha rellenado nada, no ha validado nada. Ha comprobado que una máquina responde, no que un cliente pueda comprar.
Lo que se rompe de verdad
- Un proveedor de pago cambia su script: el botón «Pagar» ya no aparece. El servidor sigue respondiendo 200.
- Un banner de consentimiento tapa el botón de añadir al carrito en móvil. La página carga perfectamente.
- Un token de API caduca en un socio: el proceso se detiene en el paso de envío, sin que la página de inicio se entere.
- Un despliegue mueve un campo del formulario: el acceso falla en silencio para las cuentas existentes.
Ninguno de estos cuatro incidentes pone en rojo una sonda HTTP. Todos cuestan pedidos, a veces durante días, hasta que un cliente se molesta en escribir. Y la mayoría no escribe.
Reproducir el recorrido, no la dirección
La única manera de saberlo es hacer lo que hace un cliente: abrir un navegador, iniciar sesión, añadir al carrito, llegar a la pantalla de pago y comprobar que el texto esperado está ahí. Cuando un paso se rompe, quiere la captura del paso que se rompió, no un código de respuesta.
Eso es todo el producto: usted graba el recorrido una vez en su navegador, nosotros lo reproducimos y le avisamos cuando deja de funcionar. El resto —gráficas, umbrales, informes— solo existe para que esa alerta sea creíble.
¿Y entonces la monitorización HTTP?
Sigue siendo útil, y Pathly también la hace: cuesta casi nada, se ejecuta cada minuto y detecta las caídas claras. No la oponemos a los recorridos: superponemos ambas. Un servidor mudo se ve por HTTP; un pago roto solo se ve en un navegador.