What is synthetic monitoring?

Synthetic monitoring generates its own traffic. Instead of waiting for real visitors, it runs scripted checks on a schedule and treats the results as a monitoring signal: a check either passes or fails, and a failure can raise an alert. The word "synthetic" refers to that generated traffic — a scripted client rather than a real customer.

The idea is commonly defined as running automated checks against a live system on an interval and feeding the results into monitoring and alerting. A check can be as small as a single request or as involved as a full multi-step journey. What matters is that it tests behaviour you care about — availability, response time, or whether a specific sequence of actions still completes — and that it runs whether or not anyone happens to be using the site at that moment.

This makes synthetic monitoring proactive: because it does not depend on real traffic, it can surface a problem on a quiet page, overnight, or in a market you rarely check yourself, before a customer encounters it. The trade-off is scope. A synthetic check only tells you about the specific journey and conditions it was scripted to run.

Synthetic checks come in three broad types, increasing in what they can establish and in what they cost to run and maintain:

An HTTP check is cheap and simple, and it is the right tool for "is it reachable?" But a page can return a healthy 200 status while the JavaScript has errored, a button does nothing, or a script conflict blocks the next step. An API check goes deeper into service correctness but still does not exercise the page a shopper actually sees. A browser check is the only type that verifies a multi-step interaction in the rendered storefront — which is why it is the one that matters most for a purchase flow. See why an HTTP 200 store can still be broken for that gap in detail.

The clearest way to see a browser check is to walk through one. The example below is a demonstration of how a purchase-flow check is structured — it is not a report of a real customer incident. A browser check scripts each action a shopper takes before payment, then asserts the expected result. If an assertion fails, the run stops and records where it stopped.

Each row is a step the browser performs and then verifies. Passing every row means this particular journey completed on the environment tested; a failure on any row localises the problem to a specific step, which is far more actionable than "sales are down". This scripted, step-by-step form is what people mean by synthetic transaction monitoring: a sequence of the actions a customer needs to complete, each one asserted.

Synthetic monitoring and real-user monitoring (RUM) answer different questions and are usually run together rather than chosen between.

RUM instruments real sessions, so it reflects the full variety of real devices, browsers, locations and network conditions — detail that a scripted check cannot fully reproduce. Its limitation is that it is reactive: someone has to hit a problem before it appears in the data, and a low-traffic page can hide a break for a while. Synthetic monitoring is the complement: it can run on a quiet page at any hour, but only tests the specific journeys and conditions you scripted. The three-way distinction with uptime checks is covered in synthetic vs RUM vs uptime monitoring.

A synthetic check is only as broad as what it was scripted to do, so it is worth being precise about the boundary of a green result.

A successful run covers the journey and environment you tested. It does not prove that every product, market, payment method or customer session works. A test that stops before payment also does not verify that a card payment can be completed.

In practice that means a passing purchase-flow check confirms the tested product, variant and viewport reached checkout at that moment. It says nothing about a different product with its own inventory rules, a different market with different tax or shipping logic, a payment step that runs after the check ends, or an intermittent failure that happens to miss the schedule. Treating a green check as "the whole store is fine" is the most common way to be misled by synthetic monitoring — the honest reading is "this journey, on this environment, passed this run."

A useful synthetic setup is a series of practical trade-offs rather than a single dial turned to maximum.

• Which checks. Start with the journeys that matter most and are hardest to notice breaking — for a store, the purchase path from product to checkout. Cover the variations that carry real risk (for example desktop and mobile viewports, or a distinct high-volume product) rather than trying to script every possibility.
• How often. Frequency is a balance between detection speed and cost. Checking more often shortens the window in which a break can go unnoticed, but every run consumes resources and, on any monitoring product, sits within plan limits. Pick a cadence that matches how much a given journey costs you when it fails.
• Retries and false alerts. Live sites produce transient blips — a momentary timeout, a slow third-party script. Alerting on the first raw failure generates noise and erodes trust in the alerts. A common pattern is to confirm a failure with an automatic retry before alerting, so the signal reflects a real, repeatable break rather than a one-off. This adds a short confirmation delay, which is a deliberate exchange of a little detection speed for far fewer false alarms.
• Alert rules and detection speed. Because of scheduling and confirmation, detection speed is realistically the check interval plus the run duration plus any retry confirmation — not instantaneous. Route alerts to a channel the responsible team actually watches, and make each alert point at the specific failing step so it is actionable.

Applied to a specific platform, these choices become concrete: see synthetic monitoring for Shopify for how scheduled browser checks, viewports and alert options work on a live Shopify store.