Synthetic Monitoring: Testing the Paths Users Take

A shallow health check verifies that a process is running and can answer a request. It says nothing about whether the database connection that checkout depends on is healthy, whether a third-party payment call is timing out, or whether a recent deploy broke the coupon code path while leaving the root route untouched.

A synthetic probe instead walks through an actual sequence: load the page, add an item to the cart, apply a coupon, submit a test payment. If any step in that sequence fails, the probe fails, even though the server's root path would still return a perfectly healthy 200.

You don't need to simulate every page. Pick the flows where a failure directly costs revenue or trust: signup, checkout, password reset, and whatever single action is the core of your product. Running probes against every minor page adds cost and noise without adding much protection, and a flood of low-value alerts is how a team stops trusting the whole monitoring setup.

For example, a subscription product might list five candidate flows: signup, checkout, password reset, a settings page, and a help center article. Only the first three touch revenue or account access, so a sensible first version probes those and the core action of the product, and leaves the rest to real user monitoring. A common mistake is adding a new probe after every incident until nobody remembers why each one exists. The fix is a short review: for each probe, write down what it costs you when that flow fails, and retire any probe whose honest answer is not much.

Synthetic probes run from fixed locations on a schedule, which means they catch an outage before a real customer hits it, often within minutes. What they can miss is anything specific to a particular browser, region, or account state that only shows up in genuine traffic, an edge case a scripted probe never exercises.

Real user monitoring catches those edge cases but only after a real customer has already been affected. Running both together, rather than picking one, covers each other's blind spot.

• Alert on two or three consecutive failures, not a single blip, since a probe run from one location can hit a transient network hiccup that has nothing to do with your service.
• Treat a slow response and a broken response as separate alerts, since the fix and the urgency for each are usually different.
• Page a human only for flows tied directly to revenue or account access; route everything else to a ticket queue instead.

Running synthetic probes too frequently, across too many regions, without ever pruning the list, quietly adds up in monitoring cost for very little extra protection. Weigh that against the cost of an undetected outage: say a checkout outage costs your business two thousand dollars an hour in abandoned carts. A probe that catches that outage in five minutes instead of six hours can pay for a full year of monitoring in a single incident.

A probe that just fires an alert and gets forgotten only helps in the moment of the outage. Keep a record of every failure and its cause, and you start to see patterns: the same third-party payment step timing out every Monday morning, or checkout failures clustering right after a specific kind of deploy.

That history also makes incident review faster. Instead of reconstructing what happened from logs after the fact, you already have a timestamped record of exactly when the flow started failing and which step broke, which turns a vague postmortem into a specific one with a real fix attached.

Review the failure log on a regular cadence, not just after an incident. A flow that's been silently flaky for weeks without ever crossing the alert threshold is exactly the kind of problem a periodic review catches before it becomes the outage that does cross it.