Quick answer
Synthetic monitoring tests websites, apps and APIs by running scripted requests or browser journeys from controlled locations on a schedule, detecting outages and performance regressions before or without real user traffic.
What is synthetic monitoring?
Synthetic monitoring tests a website, app or API by running scripted visits from controlled locations on a schedule, instead of waiting for real users. A robot loads your homepage every five minutes from three regions, logs in and completes checkout once an hour, or calls an API endpoint every minute, and alerts you when something is slow or broken.
It is also called active monitoring or synthetic testing. Its counterpart is real user monitoring (RUM), which measures what actual visitors experience.
Types of synthetic checks
| Type | What it does | Catches |
|---|---|---|
| Uptime (ping / HTTP) | Requests a URL and checks status and response time | Outages, expired certificates, DNS failures |
| API check | Calls endpoints and validates responses | Broken or slow APIs, wrong payloads |
| Browser check | Loads a page in a real browser engine and records timings | Slow pages, script errors, layout problems |
| Transaction (multistep) | Scripts a user journey: log in, search, add to cart, pay | Broken flows that a single page check misses |
Browser checks usually report lab metrics such as largest contentful paint, total blocking time and speed index, measured under a fixed device and network profile.
Synthetic monitoring vs real user monitoring
| Synthetic monitoring | Real user monitoring | |
|---|---|---|
| Who generates the data | Scripted robots | Real visitors |
| When you learn about a problem | Before users hit it, even with zero traffic | Only after users experience it |
| Conditions | Fixed device, network, location, empty cache | Every real device, network and cache state |
| Coverage | The pages and flows you script | Every page people actually visit |
| Best for | Uptime, release checks, regressions, competitor benchmarks | Real experience, Core Web Vitals field data, prioritizing fixes |
| Main blind spot | Does not reflect your real audience | Cannot test pages or flows nobody visited |
Most teams need both: synthetic checks to know immediately when something breaks, RUM to know how slow the site feels to the people who actually use it.
Why the two disagree: a worked example
A product page measured in the same week (sample data):
| Source | Setup | Largest contentful paint |
|---|---|---|
| Synthetic browser check | Desktop, fast connection, one data center, every 15 minutes | 1.8 s (median of runs) |
| RUM, all visitors | Real devices and networks | 2.6 s at P75 |
| RUM, mobile only | Real phones on mobile networks | 3.4 s at P75 |
The synthetic check says the page is fast; mobile visitors disagree. Neither is wrong. The synthetic test measured one controlled setup; RUM measured the spread of real conditions, and Google assesses Core Web Vitals at the 75th percentile of real visits. Use the synthetic number to catch regressions after a release, and the RUM P75 to decide whether the page is good enough for your audience. See percentile and Core Web Vitals.
When to use synthetic monitoring
- Uptime and SLAs. You need to know within minutes when the site is down, including at 3 a.m. with no traffic.
- Critical flows. Sign-up, login and checkout should be exercised end to end continuously.
- Pre-release and staging. Run the same scripts before production traffic exists.
- Third-party dependencies. Detect when a payment provider, CDN or API you rely on slows down.
- Benchmarks. Compare your pages with competitors' under identical conditions.
Limitations
- Scripts break when the UI changes and need maintenance.
- A handful of locations and devices cannot represent your whole audience.
- Tests from data centers often look faster than reality, because they are close to servers and have strong connections.
- Running full browser journeys frequently from many locations gets expensive.
In TapCub
TapCub is a real user monitoring tool: its performance report measures load timing and Core Web Vitals from real visits, with P75, P95, median and average views and breakdowns by page, country, device, browser and operating system. It does not run scheduled synthetic checks or uptime tests. Pair it with an uptime or synthetic service for outage alerts, and use TapCub to see how fast pages are for the people who actually visit them. To check a page's field data, see check Core Web Vitals.
Sources
- Wikipedia. Synthetic monitoring.
- Elastic. What is synthetic monitoring?
- Google. Why lab and field data can be different.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.