Website uptime vs real customer experience

Every check is green. The page returns a 200 in 180 milliseconds. And a customer in Madrid is watching a spinner that is never going to stop, because the payment script loaded from a third-party CDN is timing out and the pay button will never become clickable.

The uptime monitor and the customer are answering two different questions. The monitor asks whether the server returned a document. The customer asks whether they can finish what they came to do. Most of the time those answers agree, which is exactly why the times they diverge are so disorienting.

What an uptime check never sees

A standard uptime check fetches the HTML and stops. It does not execute the JavaScript, wait for the third-party scripts the page depends on, render the layout, or click the button that actually matters. It confirms the document exists. It cannot confirm the page works.

Why it only breaks for some people

The failure is partial, which makes it worse. Visitors who already have the third-party script cached are fine. New visitors are not. A degraded CDN node in one region fails for that region while the rest of the world stays smooth. So the reports trickle in, geographically clustered, and each one on its own is easy to wave away.

And so it gets waved away. The team looks at the green board and tells support it must be the user’s network, their extension, their cache. The site is up; everyone can see that it is up. The tickets keep coming, because being up was never the thing the customer needed.

A site can be perfectly up and completely unusable, and uptime monitoring cannot tell the difference.

What it takes to see the real experience

The only check that catches this is one that does what the customer does: loads the page, runs the scripts, waits for the third parties, and completes the journey, from more than one region. The signal you want is "checkout could not be completed from Spain," not "the homepage returned 200." The first is the customer’s reality. The second is trivia.

Crowswatch runs the journey rather than just the request, and watches the third-party dependencies a page pulls in, so "up but unusable" stops being a thing you learn about from support.