October 12, 2026
Synthetic monitoring services: what they are and how to choose one
Your server returns 200 OK. Your home page loads. Meanwhile the payment form throws a JavaScript error and nobody can buy. A plain uptime check sees a healthy site. Synthetic monitoring is the kind of check that sees the broken form.
This guide explains what synthetic monitoring is, which checks it includes, when you need more than an uptime check, and what to ask a service before you pay for one. We build Uptrack, so we say at the end where we fit and where we do not.
What synthetic monitoring is
Synthetic monitoring is a script that uses your site on a schedule, from the outside, and tells you when it fails. General definitions agree on the shape: scripted simulations of user activity that check performance and availability. The script can open pages, complete a transaction or call an API, and it runs from chosen locations at a fixed interval, for example every five minutes.
"Synthetic" means no real user is involved. That is the main difference from real user monitoring (RUM), which collects data from actual visitors. Because the script behaves the same way every time, with the same browser and the same steps, a change in the result points at your system and not at a different visitor. It also runs when nobody visits, so it finds the outage at 3 a.m. and works before launch. RUM is better at problems that hit only some visitors, such as one country or one device. Most teams use both.
The four kinds of check
"Synthetic monitoring services" covers a range. Start with the cheapest check that catches your failure, and add the expensive kind only for flows that earn money.
| Check | What it does | What it catches |
|---|---|---|
| HTTP and API check | One request: status code, response time, sometimes a header. | The server is down, slow or returns an error. |
| Keyword check | One request, plus a search for text in the body. | The page loads, but shows an error message or an empty shell. |
| Browser flow | A script drives a real browser through several steps. | Login, sign-up or checkout is broken while every page still returns 200. |
| Ping, port, DNS, SSL | Checks below the web layer. | A host that does not answer, a wrong DNS record, a certificate about to expire. |
An uptime check is a synthetic check with one step. A browser flow has many. The difference in cost is large: a browser needs memory and time to start, renders the page, and runs your script, so services limit how many flows you get and how often they run.
When an uptime check is enough, and when it is not
An uptime or keyword check is enough when
- The page is mostly content and a failure means the server or the CDN is down.
- An error page is easy to spot with a keyword, such as "Something went wrong".
- The flow has no state: no login, no cart, no form that talks to a third party.
You need a browser flow when
- Money moves through the flow: checkout, subscription, top-up.
- A login or sign-up depends on a script that can fail without changing the status code, such as an identity provider or a captcha widget.
- Your single-page app renders an empty shell with a 200 when the API behind it fails.
- A third-party script, such as a payment form, can break the page for every user at once.
A short test: write down the three things a customer must be able to do this week. If a status code cannot prove that each one works, that is your first browser flow.
What to ask a synthetic monitoring service before you buy
Seven questions separate services faster than a feature table does.
- Script language. Do I write standard Playwright, or a recorder format only this vendor runs?
- Evidence on failure. Do I get a screenshot of the failing step, the console log and the network log, or only a red dot?
- Locations. Where does the browser run, and can I pick the place that matches my users?
- False alarms. Does one failed run page me, or must failures repeat or several locations agree?
- Maintenance. How do I update a script when the page changes, and who gets told when it breaks for a reason that is not an outage?
- Pricing model. Do I pay per monitor, per run or per step? What does one check every minute cost?
- Intervals. What is the fastest interval on the plan I can afford, for browser flows and not only for URL checks?
Evidence on failure and script language matter most. A failed check without a screenshot sends you to reproduce the problem by hand. A vendor-only recorder format means your scripts are lost if you leave. Standard Playwright scripts are portable.
Pitfalls that make browser checks noisy
Flaky scripts
Most flakiness comes from the script, not the site. The Playwright best practices recommend locators that match how a user sees the page, such as role and label, web-first assertions that retry until the page is ready, and one fresh browser context per run. Retries help, but the retries guide treats a pass-on-retry as flaky, not as fixed. A monitor that needs three tries to pass hides a real intermittent bug.
Test accounts and real money
Give the script its own account and a payment method in the provider's test mode. Never run a monitor that places real orders unless you also cancel and refund them. Reset the state at the end of each run, or the account fills with test data.
Third-party scripts
Chat widgets and trackers slow the page and fail on their own. Decide whether a failure in one of them should alert you. Often it should not: assert on the elements that matter to the customer, not on every network request.
Bot protection
A firewall or captcha can block a monitor that runs in a data center, and the check then reports an outage that is really a block. Allow-list the monitor's addresses, or send a secret header that your firewall accepts. This is practical advice from running checks, not a measured rate. Test it before you rely on the alert.
Where Uptrack fits
Uptrack is an uptime monitor first: HTTP and keyword checks every 30 seconds, plus ping, port, DNS, SSL and heartbeat checks. On top of that it runs real browser checks that log in, sign up or check out and save a screenshot at the moment a step breaks. A run also keeps the console, network and page data of the failure. The scripts are Playwright, so you bring the scripts you already write.
Browser monitors are a paid feature. Pro includes 5 browser monitors that run every 10 minutes, Team has 20 every 5 minutes, and Business has unlimited monitors every minute. You can see what a browser check shows without an account: the free browser check loads one page in a real browser and returns a screenshot and Core Web Vitals. The browser monitoring page lists what each run gives you.
When Uptrack is not for you
- Nobody on your team can write and maintain a Playwright script. Our browser checks are scripts, so someone has to own them. A no-code recorder fits that team better.
- You need load testing, application performance monitoring or real user monitoring. Those are different tools.
- You want browser flows on a free plan. The free plan has HTTP and keyword checks only.
- Your flow sits behind a captcha you cannot bypass for the monitor. No synthetic service will pass it for you.
FAQ
What is synthetic monitoring?
Synthetic monitoring runs scripted checks against a site, an API or a user flow on a fixed schedule, from known locations. The script acts like a user: it loads pages, fills forms, clicks and calls APIs, and reports when a step fails or is slow.
Is an uptime check a synthetic check?
Yes, the simplest kind. An uptime check requests one URL and judges the status code and the time. Synthetic browser checks go further and run several steps in a real browser, such as logging in or paying.
Synthetic monitoring or real user monitoring?
They answer different questions. Synthetic checks are repeatable and run when nobody is on the site, so they catch an outage at 3 a.m. Real user monitoring measures what actual visitors experience, so it shows problems that only some segments see. Most teams use both.
How often should a browser check run?
Run the flow that earns money, such as checkout or sign-up, as often as your plan allows, because it is the one you cannot afford to miss. Run secondary flows less often. Frequent runs cost more on most services.
Do browser checks replace tests in CI?
No. Tests in CI check your code before release. Synthetic checks watch the live system after release, including parts you do not deploy: your host, your DNS, your payment provider and third-party scripts.
Start with the check that catches your failure
Uptime checks every 30 seconds first. Browser flows when a status code is not proof enough.
Free: 5 monitors at 30 s · paid from $3/mo, 30-day money-back guarantee