What is synthetic monitoring? A plain-English guide

Synthetic monitoring is the practice of testing your website or app with automated, scripted checks that imitate a real user. They run on a schedule from outside your network and do not depend on live customer traffic. The generated traffic is synthetic; real-user monitoring measures visits from real users instead.

What is synthetic monitoring?

You can think of synthetic monitoring as a tireless QA tester who never sleeps. Every minute, it pretends to be a customer: it loads a page, calls an API, or clicks through a checkout, then checks that what came back is correct. Nothing about it waits for real demand. That is the key difference from analytics or real-user monitoring, which can only tell you about a problem after a real person has hit it.

It is also the engine underneath uptime monitoring: when a tool checks every 30 seconds that your homepage is reachable, that is synthetic monitoring in its simplest form. Synthetic monitoring is just the broader idea: the same scheduled, scripted approach applied to far more than “is it up?”.

Synthetic vs real-user monitoring (RUM)

The phrase you will see paired with synthetic monitoring most often is real-user monitoring, or RUM. They sound like alternatives; they are really two halves of the same picture. The simplest way to keep them straight:

Synthetic monitoring watches the door so RUM can study the room. Synthetic answers “does the checkout work?” at 4am on a bank holiday when no one is shopping; RUM answers “how fast is the checkout for our actual customers on mobile in Manchester?” The first stops outages catching you out; the second tunes the experience for the people already there.

The three types of synthetic monitoring

“Synthetic” covers a spectrum, not a single technique. The checks differ in how much of the real experience they exercise. The more they exercise, the more they can catch:

Availability checks

The classic uptime check: request a URL on a schedule and confirm it is reachable and returns the status code you expect. Cheap, fast, and the right first monitor for everything. This is where almost everyone starts; our guide to monitoring website uptime walks through it end to end.

API checks

A step deeper: call a REST or GraphQL endpoint and assert on the response body, not just the status line. Did the JSON contain the field you expected? Did it come back inside your latency budget? This catches the backend that is “up” but returning nonsense.

Browser journeys

The deep end, and the reason synthetic monitoring earns its keep: a real Chromium browser scripted to walk a multi-step flow (log in, search, add to basket, check out) exactly as a customer would. This is sometimes called transaction monitoring, and it is the only kind of check that proves a critical product flow works, not just that your server is answering the phone.

How a browser journey works

A browser journey is a short script of steps, each with an action and an assertion. The monitor spins up a genuine headless browser, runs the steps in order, and fails the moment one step does not do what it should. Here is a checkout journey caught mid-failure:

Look at what happened: every individual page returned a perfectly healthy 200 OK. A homepage uptime check, even a checkout-page uptime check, would have stayed green throughout. But the journey failed, because the order never completed. That is the failure class synthetic browser monitoring exists to catch.

What synthetic monitoring catches that a ping can't

The recurring theme is the gap between “reachable” and “working”. A web server can return a cheerful 200 OK while the page itself is useless (a database error rendered as HTML, an empty product grid, a payment form that silently fails to submit):

Richer synthetic checks treat “working” as more than reachable. They verify:

• Content, not just a status code: a keyword or text assertion proves the page rendered the expected content.
• Whole journeys, not single pages: login, search and checkout completing in sequence as a customer would use it.
• Speed as a failure mode: a step that takes 30 seconds is, to a real customer, indistinguishable from broken.
• Third parties in the path: the payment provider, the search service, the login SSO that is technically “someone else's problem” right up until it is yours.

Where and how often it runs

Because synthetic checks run from your monitoring provider rather than the visitor's browser, you choose where they run from, and running from several regions does two jobs at once. It shows you whether your site is slow or unreachable from a particular part of the world, and it kills false alarms: a single failing region is re-checked from a second location before anyone is paged.

On interval, match the cadence to the cost of the check. Lightweight availability and API checks happily run every 30 to 60 seconds; browser journeys are heavier, so they typically run every 5 to 15 minutes on your most important flows. The principle is the same one behind all good monitoring: check often enough to catch a real problem quickly, not so often that you drown in noise.

So… synthetic monitoring or uptime monitoring?

It is not a versus. Uptime monitoring is the entry point: the simplest, most essential synthetic check, and the one no site should be without. Synthetic monitoring is what you grow into when “is it up?” is no longer a big enough question.

Uptime monitoring tells you the lights are on. Synthetic browser monitoring tells you the shop can still take money.

The practical path: start with uptime and the other availability checks on every public surface, then add a browser journey for each flow that, if it broke quietly, would cost you customers. If you are weighing tools, our 247Monitor vs Better Stack comparison lines up the synthetic and browser-journey features side by side.

Getting started with synthetic monitoring

You do not need a testing framework or a spare afternoon. The sensible order of operations:

• Cover availability first: an HTTP check on every public surface, plus a keyword check where a 200 is not proof of life. See the create-a-monitor guide.
• Guard the quiet failures: an SSL check on your certificate and a heartbeat on each background job, so the silent ones don't surprise you.
• Script your money path: add a browser journey for login or checkout, the flow that would hurt most if it broke unnoticed.
• Run from more than one region and confirm failures from a second location before anything pages you.
• Route alerts where you work: Slack, Teams, Telegram, Discord, email, SMS or a webhook. Then send a test so you know it lands.

Frequently asked questions

Start with availability checks on public services, then add browser journeys for the user flows whose failure would have the greatest impact. See the browser monitoring features for the checks and failure evidence available in 247Monitor, or the official Playwright documentation for the underlying browser-test framework.