Uptime monitoring vs journey monitoring: what each one actually catches
They answer different questions, and each is useless at the other one. What both actually catch, and why the answer is normally both.
Runa7 min read
These get compared as though you have to pick one. You do not, and the framing is unhelpful, because they are not competing answers to a question. They are answers to two different questions that both matter.
What uptime monitoring is
An uptime monitor makes a request to a URL on a fixed interval and checks the response. Modern ones also check TLS certificate expiry, DNS resolution, response time and whether a particular string is present in the returned HTML.
It is cheap, which matters more than it sounds. A request costs almost nothing, so it can run every minute on every site you have, forever, and the bill stays small. That frequency is the whole value: it means you find out about a hard outage in about a minute.
What it catches: the server is down, DNS is broken, the certificate has expired, the site got slow, the homepage now says “Account suspended”.
What it cannot catch: anything that requires the page to be interacted with. Which, on a modern site, is most of what the site is for.
What journey monitoring is
A journey check runs a real browser, a full Chromium that renders and executes the page the way a visitor’s browser does, and performs a sequence of actions in one session: click this, wait for that to appear, type here, continue, confirm you arrived.
Because it is a real browser, it sees what a visitor sees. Because it is a sequence, each step can act on what the previous step revealed. That is the difference between checking that a booking page loads and checking that a booking can be made.
What it catches: a button that does nothing, a widget that never mounts, a calendar with no times in it, a checkout that loses the cart, a form that will not validate, a page that returns 200 and renders an empty shell.
What it costs: materially more than a request, because it is a browser. That is why journey checks are metered and uptime checks generally are not, in every tool including ours.
The failure that explains the difference
A restaurant’s booking widget stops opening on Friday evening after an automatic plugin update. The server is healthy the entire weekend and answers every request in under 200 milliseconds. The uptime monitor is green from Friday to Monday.
On Monday somebody asks why the weekend was so quiet. That question is not really about the plugin. It is about the fact that something was supposedly watching the site and did not notice.
Why the answer is both
Journey checks alone are the wrong shape for infrastructure failure: they are too expensive to run every minute, so a hard outage might go unnoticed for half an hour. Uptime checks alone miss everything that happens after the page arrives.
The sensible arrangement is:
- Uptime checks on every site, at the highest frequency you can afford. A minute.
- Journey checks on the flows that make money, meaning booking, enquiry and checkout, at whatever frequency the budget supports.
- One alert stream, so a failure of either kind reaches you the same way.
Which is how JourneyPing is built: uptime every minute on every site on every plan including the cheapest, and browser journeys metered by the run because they are the part that costs money. The product page goes through what a journey actually does, and pricing shows where the line between the two sits.
If you take one thing from the comparison: a green uptime dashboard is evidence that your server is running. It is not evidence that anyone can buy anything.