Synthetic monitoring is the practice of testing your website or app with automated, scripted checks that imitate a real user — running them on a schedule from outside your network so you find out something is broken before your customers do. The name is the giveaway: the traffic is synthetic, generated by robots, not waited for from real visitors.
The short version
- Synthetic monitoring runs scripted checks on a schedule, so it catches failures proactively — even with zero live traffic.
- It spans a spectrum: simple availability checks, API checks, and full browser journeys that drive a real Chromium browser through login or checkout.
- It is the opposite number to real-user monitoring (RUM), which passively measures actual visitors. The two are complements, not rivals.
- The big win is the journey: a
200 OKproves the server answered; only a scripted flow proves a customer can actually buy something.
What is synthetic monitoring?
Definition
Synthetic monitoring is the use of automated, scripted requests — from a simple uptime ping to a real browser walking through a multi-step journey — to test that a site or service works as a user expects, on a schedule and from outside your own infrastructure. Because the checks run whether or not anyone is using the site, they catch problems proactively rather than waiting for a real visitor to stumble into them.
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
- Scripted robots run on a fixed schedule
- Works with zero real traffic — even at 3am
- Proactive: usually catches the problem first
- Same steps, every time, from anywhere you choose
Real-user monitoring (RUM)
- Measures what actual visitors experience
- Needs real traffic before it can see anything
- Reactive: reflects what is happening right now
- Real devices, networks and geographies
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 actually exercise — and the more they exercise, the more they can catch:
Availability check
Is the URL reachable and returning 200?
HTTP · keyword · ping · port
API check
Does the endpoint return the right data, quickly?
REST / GraphQL · JSON assertions
Browser journey
Does the whole flow work like a real user?
login · search · checkout in Chromium
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 your product actually 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:
- 1Open homepage200 OK · 0.8s
- 2Search “wireless headphones”18 results
- 3Add top result to basketbasket · 1 item
- 4Go to checkout“Order summary” shown
- ✗Place order“Order confirmed” — timed out at 30s
Captured on failure
- Screenshot
- HTML snapshot
- Console · 3 errors
- Network log
- Playwright trace
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 actually 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:
check · store.example.com · LDN
- HTTP status200 OK ✓
- TLS certificatevalid · 41 days left ✓
- Keyword “Add to basket”not found on page ✗
- Response time6.2s · budget 3.0s !
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 actually rendered what it should.
- Whole journeys, not single pages — login, search and checkout completing in sequence, the way revenue actually happens.
- 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.
check · example.com · 5 regions
- London200 OK · 142 ms ✓
- Frankfurt200 OK · 151 ms ✓
- New York503 · request failed ✗
- Singapore200 OK · 168 ms ✓
- São Paulo200 OK · 180 ms ✓
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 — and send a test so you know it lands.
Frequently asked questions
Is synthetic monitoring the same as uptime monitoring?
Uptime monitoring is the simplest kind of synthetic monitoring — a scheduled check that asks “is it reachable?”. Synthetic monitoring is the wider family: it also covers API checks and full browser journeys that script a real Chromium browser through flows like login or checkout. Every uptime check is synthetic; not every synthetic check is just an uptime check.
What's the difference between synthetic and real-user monitoring (RUM)?
Synthetic monitoring runs scripted checks on a schedule, whether or not anyone is using the site, so it catches problems proactively — even at 3am with zero traffic. Real-user monitoring (RUM) passively measures what actual visitors experience in their own browsers. Synthetic tells you something is broken before customers notice; RUM tells you how real customers are experiencing the site right now. Most serious teams run both.
How often should synthetic checks run?
Lightweight availability and API checks suit a one-minute interval — every 30 seconds for revenue-critical endpoints. Browser journeys are heavier because they drive a real browser, so they usually run every 5 to 15 minutes on the flows that matter most, like login and checkout.
Do I still need synthetic monitoring if I already have uptime checks?
You already have the simplest form of it. The upgrade that matters is browser journeys: a 200 OK proves your server answered, but only a scripted journey proves a customer can actually log in, search and pay. If you sell or sign people up online, that is the gap worth closing.
Can I do synthetic monitoring for free?
Yes — the availability side. 247Monitor's free plan covers 25 monitors with one-minute HTTP, keyword, SSL, port, DNS and heartbeat checks from multiple regions, no card required. Browser journeys — the scripted-flow kind — start on the Starter plan at £9/month with one journey and 1,000 runs included.
The bottom line: synthetic monitoring is how you stop finding out about broken journeys from the customer who couldn't complete one. Start with availability checks everywhere, script a browser journey through the flow that pays the bills, and let the robots try to buy something every few minutes so you never have to wonder whether they can. Start monitoring free →