What is Synthetic Monitoring?

Measuring when nobody is visiting

Real-user data only exists once someone visits. If the checkout breaks at 3 a.m., nobody may notice until the first customer complains in the morning. Synthetic monitoring closes that gap: robots in different parts of the world run scenarios you define every minute or every few minutes, and raise an alert when the result deviates from what you expect.

Four kinds of check are common:

• Uptime checks: request a URL and verify the status code and response time.
• API checks: send a specific request to an endpoint and assert on the structure and values of the JSON that comes back.
• Transaction checks: drive a real browser through several steps in sequence, such as signing in, searching and adding to cart.
• Scheduled performance tests: run a Lighthouse-style lab test under identical conditions and track the trend.

Uptime monitoring done properly

"Is the site up?" sounds trivial, yet a badly configured check either misses real outages or cries wolf constantly. A useful uptime check does more than look for a 200 status. On a system that serves its error page with a 200, that check will report healthy forever, so it should also assert that an expected string, such as the page title or the company name in the footer, appears in the response body. Checks should run from several regions, and alerts should fire when at least two regions fail together rather than on one region's network hiccup. Certificate expiry and DNS resolution belong in the same plan.

Availability targets are expressed as percentages, and small differences add up. Over a 30-day month, 99.9% availability leaves roughly 43 minutes of downtime, while 99.99% leaves about four. Returning 503 Service Unavailable during planned maintenance, and defining a maintenance window in the monitoring tool, keeps those figures meaningful.

Scripting multi-step journeys

Transaction checks are usually written with browser automation tools such as Playwright or Puppeteer. They look much like end-to-end tests; the difference is that they run continuously against production:

import { test, expect } from '@playwright/test';

test('sign-in and cart flow', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.getByLabel('Email').fill(process.env.MONITOR_USER);
  await page.getByLabel('Password').fill(process.env.MONITOR_PASSWORD);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await page.goto('https://example.com/product/sample-product');
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await expect(page.getByText('1 item in your cart')).toBeVisible();
});

Scripts that run in production have side effects worth planning for. They must not place real orders, touch stock levels or pollute analytics. Dedicated test accounts, journeys that stop before payment, and filtering monitoring traffic out of analytics are the standard safeguards.

Synthetic and RUM side by side

Synthetic tests can also gate releases: if a build on staging breaks the agreed performance budget, it is stopped before it reaches production.

Setup details that matter

• Pick locations near your users. Testing a site whose visitors are mostly in Turkey only from the United States overstates latency.
• Look behind the cache. A CDN can keep serving cached pages while the origin is down, so at least one critical check should hit an uncached endpoint that reaches the origin.
• Balance frequency and cost. Browser-based journeys cost far more than simple HTTP checks; run critical flows often and the rest less frequently.
• Keep alerts actionable. Every alert should reach a person and require an action, because an alarm that never stops ringing soon gets ignored. Treat synthetic checks as part of your observability setup alongside logs and metrics.