What Is Synthetic Monitoring?

A basic uptime check answers one question: did the server respond? Synthetic monitoring answers a much more useful one: can a real person actually do the thing they came to do — log in, complete a checkout, submit a form — end to end, right now.

What "synthetic" actually means here

The word comes from the fact that no real human is involved — a script simulates the steps a user would take, on a schedule, from an external vantage point. That's the same distinction that separates it from real user monitoring (RUM), which passively observes actual visitors as they use the site. Synthetic monitoring is proactive and scripted; RUM is passive and only sees what real traffic happens to exercise.

A synthetic check might: load the homepage, click through to a login form, submit valid credentials, wait for the dashboard to render, and confirm a specific element appears — then repeat that same sequence every few minutes, from one or more locations, indefinitely.

What it catches that a simple uptime check misses

A server can return 200 OK for a homepage while a critical multi-step flow is completely broken three clicks deep — a payment processor integration failing, a database query timing out only on the checkout page, a JavaScript error that only appears after login. None of those show up in a check that only requests one URL and confirms it responds.

Synthetic checks are also the only practical way to monitor things that have no single URL to poll at all: a multi-step signup wizard, a search-then-filter-then-add-to-cart flow, or anything gated behind authentication that a plain HTTP request can't get past on its own.

Where it fits alongside other monitoring

Synthetic monitoring isn't a replacement for basic uptime and response-time checks — it's a layer on top of them. Uptime checks are cheap to run frequently and catch the most common failure (the server is simply down). Synthetic checks are more expensive to build and run slightly less frequently, but catch the failures that only appear once you actually try to use the site the way a customer would.

A reasonable setup runs lightweight uptime/ping checks every minute for fast failure detection, and a smaller number of synthetic user-journey checks every few minutes to catch the deeper functional failures that a simple response check can't see.

The tradeoff worth knowing

Synthetic checks are more brittle than simple pings — if the login page's HTML structure changes, a script written against the old structure will start failing even though the site itself works fine, producing a false alarm. That's a maintenance cost real teams underestimate when they first build synthetic checks: the checks need updating whenever the flow they simulate changes, or they start generating noise instead of signal.

Frequently Asked Questions

Is synthetic monitoring the same as automated browser testing?

They use similar tooling (scripted browser automation), but different goals: automated tests run once per code change to catch regressions before deploy; synthetic monitoring runs continuously in production to catch failures as they happen in the live environment.

Do I need synthetic monitoring if I already have uptime checks?

Uptime checks catch "the server is down." Synthetic checks catch "the server is up, but the checkout flow is broken" — a different and often more business-critical failure mode that a response check alone can't see.

How often should synthetic checks run?

Less frequently than basic uptime checks, since they take longer to execute and are more resource-intensive — every few minutes is typical, versus every minute or less for a simple ping or HTTP check.

Stop checking this by hand

NetTests runs this kind of check on a schedule, stores historical results, and alerts your team the moment something changes.

Start monitoring free →
No credit card required  ·  Free plan available