Guide
What is synthetic monitoring? How it differs from uptime checks and real user monitoring
What synthetic monitoring is, what it catches that uptime checks and real user monitoring miss, and how to choose which customer journeys to monitor first.
Updated
In short
- Synthetic monitoring runs a scripted customer task on a schedule, from outside your systems, and checks the result.
- Uptime checks ask whether a URL answered. Synthetic checks ask whether a customer could finish the task.
- Real user monitoring measures what real visitors experienced. Synthetic monitoring tests a task even when nobody is using it.
- Start with the two or three journeys whose failure costs the most, and define success as an outcome a customer would see.
- A failure needs evidence, such as the step that failed, a screenshot and the network log from the same run.
Synthetic monitoring means testing your service with scripted, artificial customers. A check opens your site or calls your API, does what a customer would do, and checks that the result is what a customer should see. It runs on a schedule, from locations on the public internet, whether or not real customers are using the service at that moment.
The word “synthetic” is about the traffic, not the result: the customer is simulated, but the site, the network, the third-party scripts and the payment provider are all real.
What a synthetic check does
A synthetic check is a short script with assertions:
- Open the starting page or call the first API endpoint.
- Act like a customer. Click, fill in fields with agreed test data, choose options, submit.
- Assert at each step. The button is visible before it is clicked; the price appears after the quote is requested; the confirmation shows a reference.
- Record what happened. Timings for each step, a screenshot, the page HTML and the network requests.
- Alert on a pattern. Usually after two failed runs in a row, so one network wobble does not wake anyone.
Simple synthetic checks call a single URL or API. Browser checks drive a real browser through a multi-step journey such as sign-in, search, quote, booking or checkout. The browser kind is the one that catches the failures customers notice, because so much of a modern page is assembled in the browser.
Synthetic monitoring vs uptime monitoring
Uptime monitoring is the simplest synthetic check: request a URL, expect a success status within a time limit. It answers “is it up?”.
That question misses most of the ways a customer journey breaks:
- The page loads but the task fails. A missing button, a script error or a rejected postcode all arrive with
200 OK. - The failure is in the browser. Third-party scripts, consent banners, address lookups and payment fields load after the HTML, where an HTTP check never looks.
- The failure is several steps in. The landing page is fine; the pricing call on step four is not.
A synthetic journey check asks “could a customer complete it?”. The two are complementary: keep the uptime check, and add journey checks for the tasks that matter. The guide on availability and task success goes further into why the two numbers disagree.
Synthetic monitoring vs real user monitoring
Real user monitoring (RUM) records what real visitors experienced: page load times, JavaScript errors, the browsers and countries they used. It is the best source of truth about real experience, and it has three gaps that synthetic monitoring fills:
| Real user monitoring | Synthetic monitoring | |
|---|---|---|
| Needs real traffic | Yes: no visitors, no data | No: runs on a schedule regardless |
| Finds a problem before customers do | Rarely: a customer has to meet it first | Yes: the check meets it first |
| Tells you whether the task completed | Indirectly, from funnel drop-off | Directly, from the assertion at each step |
| Comparable from one run to the next | No: every visitor’s device and network differ | Yes: same steps, same data, same locations |
| Covers quiet periods and new releases | Poorly: overnight and just after a deploy traffic is thin | Yes: run straight after each release |
Most teams use both. RUM tells you something changed for real visitors; a synthetic check tells you whether the task still works, and exactly where it stops.
What synthetic monitoring catches
- Broken forms: the submit button missing, disabled or covered, or valid answers rejected. See how to detect a broken form.
- Failed third parties: address lookup, identity checks, pricing services and payment fields that fail in the customer’s browser.
- Release regressions: a deploy that passes every pipeline test and still breaks the journey in production. See checking journeys after every deployment.
- Regional problems: DNS, CDN, certificate or consent failures that only appear from certain countries.
- Slow steps: a journey that still completes but takes ten seconds longer at one step.
- Checkout and booking failures: see monitoring checkout and payments and monitoring a booking journey.
How to start
- Choose two or three journeys. The ones whose failure costs the most money or causes the most harm: getting a quote, buying, booking, signing in, making a claim.
- Write each as a customer task with an outcome: “Get a travel insurance quote and see a price”, not “check the quote page”.
- Agree test data with the owners of the service: test accounts, test cards, products or slots that can take test orders, and how test records are cleaned up.
- Mark the traffic with a header or query parameter so analytics, fraud rules and revenue reports can exclude it.
- Pick a schedule. Every five to fifteen minutes for revenue journeys is a sensible start, plus a run after each release.
- Decide who gets the alert and what they need in it: the journey, the failed step and a link to the evidence.
You can build this with open-source browser automation such as Playwright and a scheduler. The work that grows over time is keeping the scripts current as pages change, running them from several locations, storing evidence and turning failures into alerts without noise.
How ScoutSentinel does it
ScoutSentinel is synthetic monitoring for customer journeys. You describe a task in plain words; it proposes the steps and assertions; you review and approve them before anything runs.
- Checks run in a real browser or through your API, from outside your systems.
- By default an event opens after two consecutive failures at the same step, and resolves after two passes.
- Each run keeps screenshots, the page HTML, the network log and timings, each hashed at capture.
- Every request carries the documented ScoutSentinel user agent and a probe header, and you can add your own marker, so the traffic is easy to allow and to exclude from analytics. See synthetic traffic.
- A run that could not complete for reasons on our side is recorded as unknown, with the reason, not as a failure of your service.
The home page follows one check through a failure: our demo insurance site loses its “Get quote” button while its uptime check stays green.
Run your first synthetic check
Describe a customer task in plain words. ScoutSentinel proposes the steps, you approve them, and the check runs from outside your systems with evidence kept for every run.
Free 14-day pilot by invitation. No card required. Starter limits apply unless we agree a scoped one-service evaluation. When the trial ends, the organisation is suspended until you choose a plan: scheduled checks stop, and your journeys and checks stay in your account. See pricing.