Cloud Parts

Synthetic monitoring

Robots that use your product from outside on a schedule, so you learn it’s broken before a customer tells you.

3 technologies on this page ↓
Live model
What you’re watchingReal users come and go, but three probes in different regions check the shop every couple of seconds. When the shop goes down during a quiet spell, the probes’ checks are missed straight away, long before any user would notice.

How it works

A synthetic monitor is a scripted check that runs from outside your system on a timer, from several locations. The simplest is an uptime check: request a URL every minute and expect a 200 status, a keyword in the body and a valid TLS certificate. An API check sends a real request with headers and a body and asserts on the JSON that comes back. A browser check drives a headless browser through a user journey with a script, usually Playwright or Puppeteer: open the login page, sign in with a test account, add an item to the cart, and assert that the order page appears, recording timings, screenshots and the network log. Each check runs from probes in different regions, and the monitor alerts only when it fails from more than one place, often after a retry, so a flaky network path in one city doesn’t page anyone. Because the traffic is generated, it arrives at 3 a.m. and on a brand-new feature with no users yet, which is the point. The counterpart is real user monitoring (RUM), a script in real users’ browsers or apps that reports what they actually experienced. Synthetics give a steady, comparable signal on the paths you chose; RUM covers every path, but only where and when people show up.

Think of it as

A mystery shopper who visits every branch every hour, tries the front door, buys one thing and phones head office the moment a door is locked, instead of waiting for angry customers to write in.

Reach for it when

  • Login, sign-up, search and checkout: the few journeys that must always work
  • Low or uneven traffic, where a failure could go unseen for hours
  • Checking from the outside: DNS, TLS certificates, CDNs and third-party APIs that internal metrics never see
  • Right after a deploy, to confirm the critical paths still work

Think twice when

  • As a replacement for real user monitoring: probes from data centres miss slow phones, odd browsers and paths you didn’t script
  • Long, brittle browser scripts that break on every UI change and train people to ignore failures
  • Journeys with side effects you can’t undo, such as real payments, unless the test account is sandboxed

A real example

A shop runs a browser check every 5 minutes from five regions: sign in with a test account, search for “kettle”, add one to the cart and reach the payment page. At 02:40 a certificate on the payment service expires. Every probe fails twice in a row, an alert pages the on-call engineer with a screenshot of the browser error, and the certificate is renewed at 02:58. The first customer email would have arrived after 7 a.m.

Used for synthetic monitoring

Synthetic monitoring is something products do, not a kind of product. These are often used for it, grouped by what they are.

What each provider calls it

AWS
CloudWatch Synthetics canaries (scripts on Lambda, Playwright, Puppeteer or Selenium); Route 53 health checks
Google Cloud
Cloud Monitoring uptime checks and synthetic monitors (Cloud Run functions)
Azure
Application Insights availability tests (Standard tests; URL ping tests are deprecated)
Open source & others
Prometheus Blackbox exporter (Apache 2.0), Uptime Kuma (MIT, self-hosted); hosted: Checkly, Datadog Synthetic Monitoring, Grafana Cloud Synthetic Monitoring, Better Stack Uptime, Sentry uptime monitoring

Synthetic checks or real user monitoring?#

Most teams run both: synthetics to catch outages fast on the paths that matter, RUM to see what people really experience.

Synthetic monitoringReal user monitoring (RUM)
TrafficGenerated by probes on a scheduleReal sessions, recorded in the browser or app
Works with no usersYes: at night, before launch, on new featuresNo: no users, no data
CoverageOnly the journeys you scriptedEvery page and device people use
SignalSteady and comparable run to runNoisy: devices, networks and behaviour vary
Typical productsCloudWatch Synthetics, Checkly, Datadog SyntheticsCloudWatch RUM, Datadog RUM

In code · ts

// A browser check: Playwright Test, as Checkly, Datadog and CloudWatch Synthetics run it
import { test, expect } from '@playwright/test';

test('a shopper can reach checkout', async ({ page }) => {
  await page.goto('https://shop.example.com/');
  await page.getByRole('link', { name: 'Sign in' }).click();
  await page.getByRole('textbox', { name: 'Email' }).fill(process.env.PROBE_USER!);
  await page.getByRole('textbox', { name: 'Password' }).fill(process.env.PROBE_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await page.getByRole('searchbox').fill('kettle');
  await page.getByRole('button', { name: 'Add to cart' }).first().click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await expect(page.getByRole('heading', { name: 'Payment' })).toBeVisible();
});

Often confused with

Load balancersCanary releasesAlertingObservability
Where it came from1995–2020

Checking a service from outside is as old as the web. Keynote Systems, founded in 1995, sold measurements of website performance taken “from the end user perspective” rather than from inside the data centre. Google’s SRE book later named the approach black-box monitoring, “testing externally visible behavior as a user would see it”, and described it as symptom-oriented: it shows active problems, “The system isn’t working correctly, right now”, while white-box metrics from inside the system can warn of problems before they hit users.

Simple pings grew into full user journeys thanks to browser automation built for testing. Selenium started in 2004 at ThoughtWorks, where Jason Huggins wrote a JavaScript test runner for an internal expenses app. Headless Chrome and Puppeteer, which reached 1.0 in January 2018, and Microsoft’s Playwright, 1.0 in May 2020, made it cheap to run a real browser in a script, and monitoring vendors started running those same scripts on a schedule.

The clouds followed. AWS made CloudWatch Synthetics generally available in April 2020, calling its scripts canaries and pitching them as a way to “discover issues before your customers do” even with no customer traffic. Google Cloud runs uptime checks from checkers in several regions and synthetic monitors as Cloud Run functions, and Azure Application Insights runs availability tests from up to 16 locations; Microsoft deprecated its simpler URL ping tests and has pushed their retirement to September 2028.

Why it’s built this way

Probe from outside, from several places
A check inside the data centre can’t see a broken DNS record, an expired certificate or a CDN outage. Azure recommends at least five test locations so you can tell a problem with your site from a problem with one network path.
Script whole journeys, not just pings
A home page can return 200 while login or checkout is broken. Browser scripts exercise the paths that make money, the same way a user does.
Retry before alerting
The internet drops the odd request. Azure says about 80% of failures disappear on retry, so monitors usually retry, or require failures from several locations, before paging anyone.
Generated traffic on purpose
Real users are the best signal when they are there. Synthetic traffic exists for the times they aren’t: nights, weekends, new features and low-traffic regions.

Timeline

  1. 1995

    Keynote Systems founded to measure websites from the user’s side

  2. 2004

    Selenium starts at ThoughtWorks

  3. 2016

    Google’s SRE book describes black-box monitoring

  4. 2018

    Puppeteer 1.0 for scripting headless Chrome

  5. 2020

    CloudWatch Synthetics generally available (April); Playwright 1.0 (May)

Sources14

Improve this page on GitHub