April 2026

An HTTP 200 never proves a customer can pay

Journeys

Monitoring is green, the homepage answers in two hundred milliseconds, and yet nobody has ordered since Tuesday. That situation is where Pathly comes from.

What an HTTP check actually looks at

An HTTP check opens an address, reads the status code, and closes. If the server answers 200, it concludes that all is well. That is accurate, and nowhere near enough: it clicked nothing, filled nothing, confirmed nothing. It verified that a machine answers, not that a customer can buy.

What actually breaks

• A payment provider changes its script: the “Pay” button no longer renders. The server still answers 200.
• A consent banner covers the add-to-cart button on mobile. The page loads perfectly.
• An API token expires at a partner: checkout stops at the shipping step, while the homepage stays untouched.
• A release moves a form field: sign-in silently fails for existing accounts.

None of these four incidents turns an HTTP check red. All of them cost orders, sometimes for days, until a customer bothers to write in — and most never do.

Replay the journey, not the address

The only way to know is to do what a customer does: open a browser, sign in, add to cart, reach the payment screen, and check that the expected text is there. When a step breaks, you want the screenshot of the step that broke, not a status code.

That is the whole product: you record the journey once in your browser, we replay it for you, and we tell you when it stops working. Everything else — charts, thresholds, reports — exists only to make that alert credible.

So what about HTTP monitoring?

It stays useful, and Pathly does it too: it costs almost nothing, it runs every minute, it catches outright outages. We do not pit it against journeys, we layer both. A silent server shows up over HTTP; broken checkout shows up only in a browser.