PathAugust 2026
10,000 checks a day
Pathly now runs 10,000 checks a day. The number itself means nothing; what had to be fixed to get there does.
What the number counts
Those 10,000 daily checks mix two very unequal things. Most are HTTP calls: they cost a few dozen milliseconds and come back every minute. The rest are browser journeys: a real Chromium that opens a site, clicks, fills a form and verifies that an expected piece of text shows up. They cost thousands of times more, so they run far less often.
The counter includes our own demo journeys and trial accounts. We are not going to present it as commercial traction: it measures load, not revenue.
What that volume teaches you
The first lesson is unpleasant: most failures we saw did not come from the monitored sites, they came from our own scenarios. A selector that was too specific, a consent banner showing up one day in three, a timeout tuned for a fast network. A monitoring tool that cries wolf loses its purpose within two weeks: that is where most of the work went.
The second is more useful: when a journey really breaks, it almost always breaks because of something that does not belong to the site. A payment script, a library loaded from a third-party domain, a consent service, a remote font. The site did not change; its surroundings did.
One test city, and we say so
All our journeys start from Europe. For a long time we advertised a choice of seven cities while only one probe actually ran: a measurement could show up as “Madrid” in a report. That was false, and a customer paying per city was paying twice for the same measurement. We removed the fake choice rather than let it live on. The other cities will come back when the matching probe exists.
What comes next
Three jobs, in this order: make scenarios more tolerant of small interface changes without making them blind to real outages; open a second test city when volume justifies it; and shorten the delay between failure and alert, which stays the only metric a customer remembers.