Why your uptime monitor says everything is fine while nobody can buy

A standard uptime monitor sends an HTTP request to a URL and records the status code and the time it took. If the answer is 200, the check passes. That is a genuinely useful thing to know, and it is also almost the only failure mode that does not cost you money — because a server that is entirely down is a failure you find out about from customers within the hour anyway.

The failures that quietly cost revenue all return 200.

What a 200 does not tell you

• The payment provider's script failed to load, so the card field never rendered. The page is fine. There is nowhere to type a card number.
• A JavaScript error on the cart page stops the "Continue" button from doing anything. The page returns 200 every time it is requested.
• A price is rendering as NaN, or the total is wrong, because a currency or tax lookup failed.
• Stock is showing as unavailable for everything, due to a failed sync with the inventory system.
• The shipping step rejects every postcode after a validation change.
• A third-party consent banner is covering the pay button on mobile and cannot be dismissed.
• The form submits, takes the payment, and the confirmation step throws — so the customer pays and believes it failed.

Every one of those is a 200 on the checkout URL. An uptime monitor has no mechanism to notice any of them, and it is not a deficiency in the tool — it is answering the question it was asked.

Why "check that the page contains a word" is not the fix

The usual next step is keyword matching: fetch the page, assert that it contains "Add to basket". This catches a little more and gives a false sense of coverage, for two reasons.

First, most checkouts render in the browser. The HTML that arrives from the server often contains almost none of the text a customer sees, so a fetch-and-match check is reading a document the customer never reads. A broken payment field frequently lives entirely in JavaScript that a plain HTTP request never executes.

Second, the presence of a button says nothing about whether pressing it works. The whole category of failure above is a control that exists, renders correctly, and does nothing.

The question worth asking instead

Can a customer still get from the product page to a payment form? Answering that requires doing it: a real browser, loading the real page with its real scripts, clicking the real controls in order, and asserting on what a customer would see at the end.

That is a different kind of check, and it is worth being clear about the trade-offs rather than pretending there are none.

• It is slower. A browser journey takes tens of seconds where an HTTP check takes under one.
• It costs more to run, which is why nobody offers it at one-minute intervals for a few euros.
• It breaks when you redesign, because a step that referred to a control you removed cannot be completed.
• It is noisier if implemented naively — which is the real reason most teams abandon it.

The noise problem, and why it decides everything

A browser journey has far more ways to fail transiently than an HTTP request does. A slow third-party script, a bot challenge, a single dropped connection — each produces a failed run that nothing is actually wrong with. Alert on every one and within two weeks the alerts are being ignored, at which point the monitoring is worse than none: you are paying for it *and* you have taught yourself that its alerts do not mean anything.

So the thing that makes journey monitoring usable is not the browser. It is the discipline around what counts as a failure. At minimum:

1. Never alert on a single failed run. One failure is a hypothesis, not an incident.
2. Retry from a different place, on a fresh browser, after a short delay — a regional network problem and a broken checkout look identical from one vantage point.
3. Treat a bot challenge as a bot challenge, not as an outage. Being asked to prove you are human is the site working correctly.
4. Show the evidence. A screenshot of the failing step, next to the last one that worked, turns "something is wrong" into something actionable in seconds.
5. Confirm recovery the same way you confirmed the failure, so the all-clear is as trustworthy as the alarm.

A useful test of any monitoring tool, including ours: ask what it does when a check fails once. If the answer is "sends you an alert", you will be ignoring it by the end of the month.

What to monitor, if you only pick one thing

Monitor the path that takes money. Not the homepage — a broken homepage is embarrassing and obvious. The sequence from a product page to a rendered payment form is the one where a silent failure runs for a day before anyone notices, and it is the one where every hour has a number attached to it.

If you sell by enquiry rather than by checkout, the same logic points at the contact form: submit it and confirm the confirmation appears. A form that accepts input and discards it is the single most common silent failure on a small business website.

And whatever you monitor, observe rather than interfere. A check that completes a real purchase every fifteen minutes creates reconciliation work and refunds; one that stops at the rendered payment form proves the same thing and costs nothing to clean up.