Real users find problems by running into them. Synthetic monitoring finds them first, by acting like a user on a schedule: every few minutes, from several locations, around the clock. Because the same script runs the same way every time, it also gives a clean baseline for comparing performance across releases and regions.
How it works
- Script the transaction. Define the steps: request a page or call an API, log in, add an item, check out. Browser checks drive a headless browser; API checks send a chain of HTTP requests.
- Add assertions. Each step checks the status code, response time, headers or content, for example that the response contains an order ID.
- Schedule it from several locations, so a regional problem isn't mistaken for a global one, and vice versa.
- Alert when a step fails or slows down, ideally only after a retry or a failure from more than one location, to avoid false alarms.
Types of synthetic checks
- Uptime checks: a single HTTP, TCP, DNS, ICMP or SSL check that confirms an endpoint is reachable and healthy.
- Multistep API checks: a sequence of API calls that pass data between steps, such as getting a token and then using it.
- Browser transaction checks: scripted user journeys in a real browser, often written with tools like Playwright or Selenium.
Synthetic monitoring vs. real user monitoring
| Synthetic monitoring | Real user monitoring (RUM) | |
|---|---|---|
| Traffic | Scripted, on a schedule | Actual visitors |
| Works with no users | Yes: nights, weekends, before launch | No |
| Coverage | Only the journeys you script | Every page and path users take |
| Best for | Availability, SLAs, early warning, baselines | Real experience across devices, browsers and networks |
The two complement each other. See real user monitoring vs. synthetic monitoring.
Good practices
- Script the journeys that make money or block users first: login, sign-up, search, checkout.
- Use dedicated test accounts and keep synthetic traffic out of business analytics.
- Update scripts together with the features they test, or they will fail for the wrong reasons.
- Check third-party dependencies you rely on, not just your own endpoints.
Synthetic monitoring with Atatus
Atatus uptime monitoring runs synthetic checks around the clock from multiple locations: HTTP, SSL, DNS, TCP, ICMP and UDP checks, plus multistep API checks that chain requests the way a client would, such as logging in and then fetching an order. Assertions on status, headers, body and response time decide whether a check passes, and alerts can wait for retries or failures from several locations before notifying you. Multistep checks work at the API level; to see what users experience in the browser, pair them with real user monitoring. For more, read what is synthetic monitoring.