What Is Synthetic Monitoring? How It Works and When to Use It.

Synthetic monitoring sends scripted, predictable traffic to your services around the clock - a robot customer that never sleeps. Because the robot does the same thing every time, any change in the result points to a change in your system, often before real users arrive to notice it.

Key takeaways

• Synthetic checks simulate requests or user journeys on a schedule, from chosen locations.
• They work even when no real users are active - at night, before a launch, on new features.
• Real-user monitoring (RUM) shows what actual visitors experience; synthetic shows whether key flows work right now.
• Start with simple checks on critical endpoints, then add multi-step flows for login and purchase.
• Keep synthetic tests safe: test accounts, read-only actions, clear labels.

Synthetic vs real-user monitoring

They complement each other: synthetic checks tell you the checkout works at 3 a.m.; RUM tells you it's slow on older phones.

Kinds of synthetic checks

From simplest to richest:

1. Availability checks - an HTTP request to a URL, expecting a status code. See website monitoring.
2. Content checks - the response must contain (or not contain) specific text. See keyword monitoring.
3. API checks - request with headers and body, assertions on JSON fields. See API monitoring.
4. Multi-step API flows - several dependent requests: log in, use the token, follow returned IDs. See multi-step checks.
5. Browser journeys - a scripted real browser clicking through pages. The most realistic and the most fragile.
6. Network checks - ping, TCP and UDP probes for infrastructure.

What to cover first

Pick flows by business impact:

1. The homepage and main landing pages (content check).
2. Login (multi-step: form or API login, then a page only logged-in users can see).
3. The money path: product to cart to payment page, or the order API.
4. Public API endpoints your partners or mobile apps use.
5. Background processes via heartbeat checks.

Designing good synthetic tests

• Assert on outcomes, not just status codes. The page should contain the user's name after login, the API should return a non-empty list.
• Use dedicated test accounts with no real data and limited permissions.
• Avoid side effects. Don't place real orders or send real SMS; use sandbox modes or test records.
• Label the traffic with a recognisable User-Agent so analytics can exclude it.
• Run from several locations to separate regional network problems from real failures.
• Keep scripts short. Long, brittle scripts break on harmless UI changes and train people to ignore alerts.

When synthetic checks fail

A failed synthetic check is a strong signal because the input is constant. Read the result in layers: did DNS resolve, did the connection open, which step failed, what did the response contain? Multi-step checks that report the failing step save most of the investigation.

Frequently asked questions

• Is synthetic monitoring the same as uptime monitoring?

  +

  Uptime monitoring is the simplest form of synthetic monitoring. Synthetic monitoring also covers multi-step flows, assertions and scripted journeys.

• How often should synthetic checks run?

  +

  Critical flows every 1-5 minutes; heavier browser journeys every 10-15 minutes is common.

• Can synthetic checks replace testing before release?

  +

  No. They watch production continuously; tests catch problems before they reach it. Many teams reuse the same flows in both.