Guides »

Synthetic Monitoring: Tools and Techniques

By Andy Hawkes
Reading Time 7 Minutes

What is Synthetic Monitoring?

Synthetic monitoring is the practice of testing your website, web application, or API with automated, scripted checks that run on a schedule from locations outside your own infrastructure. It’s also called site monitoring or active monitoring. The checks simulate a user or API client and alert your team when a critical flow becomes unavailable, returns an error, or exceeds a response time threshold.

The word “synthetic” refers to the traffic because it’s generated by bots running scripts rather than by real visitors. This allows a monitor to test your checkout flow at 3 a.m. on a holiday weekend, even when no customer has used it recently. If the flow breaks, your team can receive an alert without waiting for a user to report the problem.

Synthetic monitoring and load testing use similar scripted traffic at different scales. Monitoring runs continuously with one or a few simulated users, while load testing runs periodically with many users to measure behavior under heavy traffic. Many teams use both and reuse the same scripts where possible.

How Synthetic Monitoring Works

A synthetic monitor has three main parts: a script, a schedule, and an alerting policy.

The script defines what to check. It might be as simple as loading a single page or calling one API endpoint, or as involved as a complete user journey: log in, search for a product, add it to the cart, and check out. A simple page or endpoint check can detect an outage. A multi-step journey can detect a more specific failure where the site is online but a critical workflow is broken.

The schedule determines how often the check runs, typically every one to five minutes for critical checks. Each run (Loadster calls each run a cycle) either completes within your thresholds or fails. Over time, these results create an uptime and performance history for that flow.

Running the checks from outside your infrastructure tests more of the path that real users depend on. An internal health check might miss DNS problems, expired TLS certificates, CDN failures, or regional routing issues. Running the same monitor from several regions can also help you determine whether a problem is global or limited to one location.

When a check fails, the monitoring system sends an alert through the configured channels. Useful alerts include enough diagnostic detail, such as response codes, timings, and screenshots, to help your team begin investigating without first trying to reproduce the failure manually.

Synthetic Monitoring versus Real User Monitoring (RUM)

Real user monitoring takes the opposite approach: instead of generating traffic, it passively measures the experience of actual visitors, usually via a JavaScript snippet on your pages.

The two approaches answer different questions. Synthetic monitoring asks whether a particular scripted flow is working right now. It repeats the same steps under controlled conditions, which produces a consistent baseline even when the site has no active visitors. Real user monitoring shows what actual users experience across a wide variety of devices, networks, pages, and geographic locations.

Synthetic checks only cover the flows you choose to script, so they won’t detect a problem on an unmonitored page. Real user monitoring covers the pages that visitors use, but it can only report a problem after someone is affected. It might also miss a complete outage if the page never loads far enough to send its telemetry, and it provides little information during periods with no traffic.

That’s why synthetic monitoring and real user monitoring are usually complementary. A team might start with synthetic checks for its most critical flows and add real user monitoring to understand the range of experiences across actual traffic.

Synthetic Monitoring, Synthetic Testing, and Synthetic Load Testing

These terms are sometimes used loosely, but they describe related practices at different scales.

Synthetic testing is the umbrella: exercising a system with scripted, artificial traffic rather than waiting for organic usage. Synthetic monitoring is synthetic testing run continuously at small scale, with one or a few simulated users checking availability and performance on a schedule. Synthetic load testing is synthetic testing run briefly at large scale, with hundreds or thousands of simulated users measuring how the system holds up under heavy traffic.

In many cases, the same user script can support both monitoring and load testing. In Loadster, the checkout script you run every five minutes as a monitor can also run with many bots during a load test before a large launch. Reusing scripts reduces maintenance and keeps the test behavior consistent across both activities.

What to Monitor Synthetically

Start with availability and response time checks for the pages and endpoints your business depends on, such as the homepage, login page, and core API endpoints. These checks are relatively inexpensive to run and can detect a complete outage or major slowdown.

Transaction monitoring provides broader functional coverage. A script that logs in, searches, and completes a checkout verifies the application code, database, payment integration, and session handling involved in that flow. A site might pass a simple homepage check even when checkout is broken, so include at least one multi-step transaction for your most important workflow.

Consider the external services your flows depend on as well. If your application uses a payment provider, search service, or authentication vendor, a transaction check that exercises the integration can alert you when that dependency affects your users.

On frequency: every one to five minutes is typical for lightweight uptime checks, and every five to fifteen minutes for heavier browser-based transaction checks. Faster cadences find problems sooner but cost more and can generate noisier alerting, so match the frequency to how quickly each flow truly needs attention.

Synthetic Monitoring Tools

Synthetic monitoring tools fall into a few broad categories.

Large APM suites such as Datadog, Dynatrace, and New Relic include synthetic monitoring as part of a broader observability platform. This can be convenient if your team already uses the platform, although the synthetic features might be priced and packaged with many other capabilities.

Dedicated uptime services such as Pingdom and UptimeRobot focus on simple availability checks. They can be inexpensive and easy to configure, but might offer less flexibility for complete browser transactions or API sequences with custom logic.

Other platforms combine monitoring with load testing, which is where Loadster fits. Loadster monitors run the same three script types as its load tests: Protocol Bots for lightweight HTTP and API checks, Browser Bots running real Chrome for full page loads and user journeys, and Playwright scripts for teams who prefer code. Monitors run from your choice of 8 dedicated locations across 5 continents, browser-based checks capture Core Web Vitals like TTFB, FCP, LCP, and CLS, and failures open incidents that alert you by email, SMS, phone call, PagerDuty, Opsgenie, Slack, or webhooks. Hosted status pages are included if you want to share uptime with your team or customers. The Site & API Monitoring page has the full picture.

When comparing tools, consider whether you need multi-step transactions, real browser checks, several geographic locations, and integrations with the systems your team already uses to handle incidents.

Setting Up Synthetic Monitoring

You can start with a small amount of coverage and expand it as you learn which checks are most useful.

Start with an uptime check for your most important page or endpoint, running every few minutes. Then add one transaction check for a flow that would have a significant impact if it failed, such as signup, login, or checkout. Send alerts to a channel your team monitors consistently. Email might be enough to start, while Slack or PagerDuty integrations are worth setting up as monitoring becomes part of your incident response process.

From there, expand coverage gradually. The critical flows you monitor are also good candidates for load testing before your next peak traffic event.

If you’d like to try synthetic monitoring with Loadster, a free account comes with 50 units of Loadster Fuel, which is enough to run monitors and a few load tests with no credit card required.

Frequently Asked Questions

What is synthetic monitoring?
Synthetic monitoring runs automated, scripted checks against your website, application, or API on a schedule, from locations outside your own infrastructure. Instead of waiting for real users to hit a problem, synthetic checks simulate a user or API client around the clock and alert you when something breaks or slows down.
What is the difference between synthetic monitoring and real user monitoring (RUM)?
Synthetic monitoring generates its own traffic on a schedule, so it works even when no one is on your site and tests the exact same flow every time. Real user monitoring passively measures actual visitors, so it reflects real conditions but only for pages users happen to visit, and only after they’re affected. Mature teams typically use both.
What is the difference between synthetic monitoring and synthetic load testing?
Both use scripted, artificial traffic. Synthetic monitoring runs one or a few simulated users continuously to check availability and performance; synthetic load testing runs hundreds or thousands of simulated users briefly to measure how the system behaves under heavy traffic. Same scripting approach, different scale and purpose.
What should synthetic monitoring check?
At minimum, uptime and response time for your key pages and API endpoints. The bigger wins come from transaction monitoring: scripted multi-step flows like logging in, searching, or checking out, which catch broken functionality that a simple ping check would miss.
How often should synthetic monitoring checks run?
Every one to five minutes is typical for critical uptime checks, while heavier multi-step transaction checks often run every five to fifteen minutes. The right cadence balances how quickly you need to know about an outage against the cost and noise of frequent checks.