Agosto de 2026

10.000 verificaciones al día

Tras la escena

Pathly ejecuta ahora 10.000 verificaciones al día. La cifra en sí no tiene interés; lo que hubo que arreglar para llegar ahí, sí.

Qué cuenta esta cifra

Esas 10.000 verificaciones diarias mezclan dos cosas muy desiguales. La mayoría son llamadas HTTP: cuestan unas decenas de milisegundos y vuelven cada minuto. El resto son recorridos de navegador: un Chromium real que abre un sitio, hace clic, rellena un formulario y comprueba que aparece un texto esperado. Cuestan miles de veces más, así que se ejecutan mucho menos a menudo.

El contador incluye nuestros propios recorridos de demostración y las cuentas de prueba. No vamos a presentarlo como tracción comercial: mide carga, no ingresos.

Lo que enseña ese volumen

La primera lección es desagradable: la mayoría de los fallos que vimos no venían de los sitios vigilados, sino de nuestros escenarios. Un selector demasiado preciso, un banner de consentimiento que aparece un día de cada tres, un tiempo de espera ajustado a una red rápida. Una herramienta de vigilancia que grita «al lobo» pierde su razón de ser en dos semanas: ahí fue el grueso del trabajo.

La segunda es más útil: cuando un recorrido se rompe de verdad, casi siempre se rompe por algo que no pertenece al sitio. Un script de pago, una biblioteca cargada desde un dominio de terceros, un servicio de consentimiento, una tipografía remota. El sitio no ha cambiado; su entorno, sí.

Una sola ciudad de prueba, y lo decimos

Todos nuestros recorridos parten de Europa. Durante mucho tiempo mostramos una elección de siete ciudades cuando solo una sonda funcionaba de verdad: una medición podía aparecer como «Madrid» en un informe. Era falso, y un cliente que pagaba una ejecución por ciudad pagaba dos veces la misma medición. Retiramos la falsa elección en lugar de dejarla vivir. Las demás ciudades volverán cuando exista la sonda correspondiente.

Lo que viene

Tres frentes, en este orden: hacer los escenarios más tolerantes a pequeñas variaciones de interfaz sin volverlos ciegos a las averías reales; abrir una segunda ciudad de prueba cuando el volumen lo justifique; y acortar el plazo entre el fallo y la alerta, que sigue siendo la única métrica que un cliente recuerda.