What Is Synthetic Monitoring?

Last verified on Nov 8, 2026.

Synthetic monitoring runs scripted checks against your application on a schedule, from outside, and records whether they pass and how long they take. The traffic is generated by the monitor, not by your users. That is the point: it answers "does the site work right now" even when nobody is using it.

MDN defines it as monitoring performance in a controlled, laboratory-like environment, using scripts that simulate a path an end user might take through a web application and report what the simulator experiences.

What a Synthetic Check Does

A check is a small program with a schedule. Amazon CloudWatch Synthetics, a product that implements this, describes its checks as configurable scripts that run on a schedule against endpoints and APIs, follow the same routes and perform the same actions as a customer, and so let you continually verify the customer experience even with no customer traffic. They can check availability and latency, store load times and screenshots, and watch REST APIs, URLs, and page content. Scripts can be written in Node.js, Python, or Java.

Common kinds of check:

A minimal availability check, as a shell sketch you would run from a scheduler:

status=$(curl -s -o /dev/null -w '%{http_code} %{time_total}' https://example.com/health)
echo "$status"

A script like this is only a starting point. A monitoring product runs it on a schedule and keeps the history.

Where It Fits

Google's SRE book calls this black-box monitoring: testing externally visible behavior as a user would see it. It describes black-box monitoring as symptom-oriented and as representing active problems, "the system isn't working correctly, right now". Google pairs it with heavy use of white-box monitoring, which inspects internals such as logs and instrumented endpoints. The two are complementary: black-box tells you something is wrong from the outside, white-box tells you why. The SRE workbook also notes that black-box probes can be fed into canary analysis to separate a release's effect from unusual user behavior.

Good uses:

• Outages with no traffic. Overnight or on a little-used path, there are no real errors to count.
• Regression checks in CI and after deploys. MDN says synthetic checks suit regression testing, and a change from baseline can fail a push.
• APIs and endpoints. CloudWatch's documentation lists REST APIs, URLs, and website content among the things checks monitor.
• Consistent baselines. A fixed environment makes before and after comparisons cleaner.

The Limits

MDN states the main limit directly: it does not reflect what real users experience, especially the long tail. web.dev explains why. Lab data, which it also calls synthetic, deliberately limits variables to a single device, network, and location, so it cannot represent the variance across real devices, networks, and geographies. A synthetic check that passes does not mean users are fine, and a failing one may reflect only the location it ran from.

Scripts also need upkeep. A multi-step journey breaks when the page changes, and a flaky check that pages people is a route to alert fatigue.

Synthetic Monitoring vs Real User Monitoring

The two answer different questions. Synthetic monitoring asks whether a known path works from a known place. Real user monitoring asks what the people using it are experiencing. Use synthetic for availability and regressions, and real user data for how performance feels across your actual audience.

Terminology trap: the CloudWatch product calls its scripts canaries, while a canary deployment is a release technique that sends a new version to a share of real traffic.

Synthetics and Sazabi

Sazabi is an AI-native observability and security platform. Sazabi does not offer synthetic checks, so keep your synthetic monitoring tool for those. For failures that real traffic does produce, see the guides on client errors, frontend breakage, and performance degradation. For where checks fit alongside application telemetry, read about APM.