Synthetic Monitoring
Simulate real users — catch failures before they do.
A site can be "up" — returning 200 OK — while nobody can log in, complete a checkout, or submit a form. Synthetic monitoring replays the journey a real visitor takes, step by step, in a real browser: navigate, fill the form, click the button, assert the confirmation actually appeared. If the login flow breaks at 2 AM, it fails a check instead of a customer.
Why uptime monitoring isn't enough
Traditional uptime monitoring asks one question: is this URL returning a 200 response? For a static page that may be sufficient. For any application where people authenticate, interact, transact, or move through a multi-step flow, a 200 tells you almost nothing about whether the application is working.
Consider what uptime monitoring cannot detect. A login form that renders perfectly but rejects every credential because the session store is unreachable. A checkout where items add to the cart and the payment step silently fails. A signup form that submits successfully and creates no account because a migration half-applied. A search box that returns the page instantly and then hangs forever on the query.
In every one of those cases the server is up, the page is reachable, and the status code is 200 — and no visitor can do the thing they came to do. Worse, these failures are usually discovered by a customer rather than a dashboard, which means you learn about them at the worst possible moment and with the least possible information. The only reliable way to detect them is to perform the same actions a real user would and check that each one produced the expected result.
How synthetic monitoring works at NetTests
You build a flow as an ordered list of steps. There are thirteen step types — navigate, click, fill, select an option, press a key, scroll to, wait for an element, wait a fixed time, assert visible, assert text, assert URL, extract, and screenshot — and a flow can be up to 25 steps long. Elements are targeted by XPath, CSS selector, accessible label, or form field name, so you can write the selector that is most stable for your markup rather than the one the tool happens to support.
The whole flow runs in a single headless Chromium session. That is what makes real journeys possible: cookies and login state set in step 2 are still there in step 20, so a "log in, then verify the account page" flow is one check rather than an impossible sequence of isolated requests. Every step after the first must stay on the domain the flow started on, which keeps a monitor from being repurposed into a tool for hitting somebody else's site.
Steps can pass values to each other. An extract step captures text, an
attribute, the page title, or the current URL into a named variable, and later
steps reference it as {{order_id}}
inside a URL, a selector, or a value to type. That is how you check a flow that
generates something — place an order, capture the reference, then load the order
page and assert the reference appears on it.
Choose the viewport the check runs at — desktop, desktop HD, tablet, iOS phone, or Android phone — and schedule it. Flows run as part of a report, on any recurring schedule from once a week down to once a minute, and they run against the same alerting and history as every other check in your account.
Add steps in the drag-and-drop editor, pick a selector mode, and run it once to watch each step execute live.
Add the flow to a report and set the interval — every minute, every hour, or on set days at set times.
On failure the run stops, captures a full-page screenshot, and keeps the HAR — then alerts whoever needs to know.
Key features
Real browser execution
Headless Chromium with JavaScript fully enabled — your actual front-end code, your actual API calls, your actual auth flow.
Persistent session
One browser context for the whole flow, so cookies and login state carry from the first step to the last.
Thirteen step types
Navigate, click, fill, select, press a key, scroll, wait, screenshot, extract, and four kinds of assertion.
Variables between steps
Capture an order number, a token, or a redirect URL in one step and reuse it in a later selector, URL, or input value.
Screenshot on failure
When a step fails the run stops and captures a full-page screenshot of exactly what the browser was looking at.
HAR waterfall
Every request the flow made, with timing, size, and type — retained automatically on failure, or on demand for a passing run.
Security findings on every run
Mixed content, obsolete TLS versions, missing HSTS or CSP on the main document, and cookies set without the Secure flag.
Per-step thresholds
Alert on the duration of one specific step, not just the flow total — and the rule follows that step if you reorder the flow.
Five device profiles
Run the same journey at desktop, desktop HD, tablet, iPhone, or Android viewports to catch layout-dependent breakage.
Run-to-run comparison
Diff the resources of two runs to see what got added, removed, or heavier when a flow suddenly slowed down.
Console and network capture
JavaScript errors and failed requests are recorded per step, so a failure that looks like a bad selector can be traced to its real cause.
Alerts where you already work
Threshold breaches and failures go to email, Slack, and Microsoft Teams through the notification setup you already have.
What you'll see
A step timeline from a failed checkout flow — each step timed, and the run stopped where it broke.
Not ready to commit?
Open the flow builder and see exactly how a journey is put together — the step types, the selector modes, and the live timeline a run produces. Running a flow against your own site needs an account; looking at the builder doesn't.
See the flow builder →Related diagnostic tools
Check individual parts of the journey with these free tools.
Chain navigate, click, fill, and assert steps into one browser session — cookies and login state persist throughout.
Load a URL in headless Chromium and stream every fetch it makes, with timing and a full resource waterfall.
Build and send custom HTTP requests with full control over method, headers, auth, and body.
Verify that a WebSocket endpoint accepts connections and completes the upgrade handshake.
Frequently asked questions
What user flows should I monitor synthetically?
Prioritise flows where a failure has the highest business impact or the lowest discoverability. Login, signup, checkout, payment, and your key feature interactions are the usual candidates. Also consider flows that are rarely exercised — password reset, email verification, account deletion — which break silently after infrastructure changes and often aren't discovered until a user complains weeks later.
How is synthetic monitoring different from end-to-end testing?
End-to-end tests run in your CI pipeline against staging, before deployment. Synthetic monitoring runs continuously against live production. They are complementary: E2E tests verify that new code doesn't break flows before it ships; synthetic monitoring verifies that production keeps working after it does. Production has variables — real databases, third-party services, CDN and DNS configuration, expiring certificates — that staging never fully reproduces.
How do I handle authentication in a monitored flow?
Log in as part of the flow. Because every step runs in one browser session, a navigate-fill-click sequence against your login page leaves the session authenticated for every step that follows, so the flow can continue straight into the area you actually want to verify. Use a dedicated monitoring account with the minimum permissions it needs, rather than a real user's credentials, so monitoring activity stays isolated from production user data.
What happens when a step fails?
The run stops at the first failed or errored step — there is no point continuing a checkout when the login before it didn't work. NetTests captures a full-page screenshot of the browser at that exact moment, retains the HAR of every request the flow made, and records the JavaScript console errors and failed requests seen along the way. The step that failed, the reason, and the screenshot arrive together, so the diagnosis usually doesn't need a reproduction.
Can a flow visit more than one domain?
No. Every navigate step after the first must stay on the registrable domain the flow started on. This is a deliberate constraint: it keeps a monitoring feature from being turned into a tool for driving traffic at somebody else's site. Running a flow also requires that the target domain belongs to a site in your account and that you have completed domain verification for it.
How often can a synthetic check run?
Flows run as part of a report, and a report can be scheduled on set days at set times or at a fixed interval as short as one minute. In practice the right interval depends on the flow: a checkout worth monitoring every minute is a different proposition from a password reset that is fine hourly. Each step has a 10-second timeout and the whole flow is capped at 180 seconds, so a hung page fails a check rather than running indefinitely.
What is the difference between synthetic monitoring and Real User Monitoring?
Synthetic monitoring is active and scripted: it drives a browser from our datacentre on a schedule, so it produces consistent, reproducible coverage whether or not anyone is visiting. Real User Monitoring is passive: it reports Core Web Vitals from your actual visitors' devices, so it reflects the real mix of hardware, networks, and geographies — but only for the pages real traffic exercises. NetTests offers both and compares them directly for the same page, because when the scheduled run is fast and real visitors are slow, that disagreement is itself the finding. See Real User Monitoring →
Move beyond "is it up?" to "is it working?"
NetTests replays your critical journeys on a schedule, stops at the first broken step with a screenshot and a full request waterfall, and alerts your team immediately — so application failures are found by a check instead of a customer.
Start monitoring free →