PathMay 2026
Why we replay your journeys in a real browser
There are three ways to test a checkout funnel. We picked the slowest and most expensive one, and here is why it is the only one that answers the question.
Three ways to test a journey
- Chain HTTP requests while imitating a browser: fast, cheap, and wrong as soon as there is JavaScript, an anti-replay token or a payment widget.
- Drive a stripped-down browser with no rendering: lighter, but some sites detect the missing display and behave differently.
- Launch a real Chromium, with rendering, cookies and third-party scripts, and have it perform a customer’s gestures.
We took the third. It is the slowest to run and the most expensive to operate, and it is the only one that answers the actual question: can a human being buy from you right now?
What that lets you see
- The timing of each step on its own: sign-in can be instant while the cart drags, which a single overall figure hides.
- A screenshot of the failure, taken at the moment it happens.
- A video of the failing journey, on the plans that include it, when a screenshot is not enough to understand.
- The network calls of each step, with their status code and duration: that is often where the guilty third-party script shows up.
What it costs
A browser holds CPU and memory for the whole journey. That is why browser runs are counted in minutes and why their cadence is looser than an HTTP check: a few times an hour on the higher plans, once a day on the entry plans. HTTP monitoring, for its part, runs every minute.
What we did not do
We do not write scenarios for you and we do not ship a code editor. You record the journey by clicking, in the recorder, then fix steps by hand if a selector moves. That is deliberate: a scenario you do not understand is a scenario you will not repair, and a broken scenario nobody repairs becomes a scenario somebody switches off.