What is Synthetic Monitoring? Definition, Types, RUM Comparison

What is synthetic monitoring?

Synthetic monitoring is a proactive performance and availability testing technique where pre-defined scripts simulate user interactions with a website, API, or application from controlled cloud or agent locations. Unlike Real User Monitoring (RUM), which measures actual users in the wild, synthetic monitoring runs on a scheduled cadence (every minute, hour, or day) regardless of whether real traffic is hitting the system. The goal is to catch availability and performance regressions before users do.

A typical synthetic monitor sends an HTTP request, navigates a browser through a multi-step flow (login, browse, checkout), or validates an API response, then records timing, status code, and assertion results. When something fails — endpoint down, response too slow, content missing — the monitor fires an alert via Slack, PagerDuty, email, or webhook.

How synthetic monitoring works

The mechanics are straightforward but the operational details matter:

1. Define a check. A URL to hit, an API endpoint to validate, or a browser flow to walk through. The check usually includes assertions: status code 200, response body contains certain text, response time under N ms.
2. Schedule the check. Run it every minute (high-criticality services), every 5 minutes (typical), or every hour (lower-priority pages).
3. Run from multiple locations. Cloud-based synthetic monitors execute checks from agents in multiple geographic regions — typically at least one in North America, Europe, and Asia. This catches regional issues (CDN routing, peering problems) that a single-location check would miss.
4. Record results. Each run produces metrics (latency, status, body size), screenshots (for browser checks), and waterfall traces (for page-load checks).
5. Alert on failures. Configurable thresholds trigger notifications. Smart implementations require N consecutive failures or M out of N to avoid noise.

Types of synthetic monitoring

The category covers several distinct check types, each fitting different use cases:

• Uptime monitoring. The simplest — repeatedly hit a URL, confirm 200 status. Used for "is this service up?" visibility.
• API monitoring. Send a request to an HTTP/REST/GraphQL endpoint with optional auth headers and request body, assert on response status, body contents, and timing. Multi-step API tests chain requests (capture token from response 1, use it in request 2).
• Browser-based monitoring. Run a real Chromium browser to load a page, measure Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time), and capture filmstrip + waterfall data. This is the closest synthetic approximation of real-user experience.
• Transaction (multi-step) monitoring. A scripted browser flow walks through a critical user journey — login, search, add to cart, checkout — asserting each step. Failures pinpoint exactly which step broke.
• SSL/TLS certificate monitoring. Check certificate expiry, chain validity, and SSL Labs grade.
• DNS monitoring. Resolve a hostname from multiple resolvers, validate the returned IPs and TTLs.

Synthetic monitoring vs Real User Monitoring (RUM)

The two approaches measure different things and complement each other rather than competing:

Most mature monitoring strategies combine both: synthetic for "is the system working as designed", RUM for "what are users actually experiencing".

Common metrics tracked

• Availability / Uptime %. Percentage of checks that succeeded over a window. SLAs are typically expressed as availability targets (99.9%, 99.95%, 99.99%).
• Response time. End-to-end latency, often broken down by phase: DNS, TCP, TLS, server processing, content download.
• Core Web Vitals. For browser-based checks: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT). Google ranking factors.
• Error rate. Percentage of checks returning unexpected status codes or failing assertions.
• Time-to-first-byte (TTFB). Server-side responsiveness signal.
• Apdex score. Industry-standard satisfaction metric blending response time tolerance thresholds.

When to use synthetic monitoring

Synthetic monitoring is the right fit when any of these apply:

• You need 24/7 visibility. Production systems with global users need continuous checks regardless of when real users are online.
• You're testing pre-launch or low-traffic services. RUM needs traffic. Synthetic works from day one — useful for staging environments or new product launches.
• You need SLA reporting. Synthetic uptime numbers are the standard way to report against availability commitments to customers.
• You want to catch regressions early. Run synthetic checks against staging environments after every deploy to catch issues before they reach production users.
• You need geographic visibility. Multi-region synthetic monitoring detects regional CDN, DNS, or peering issues that affect specific user populations.
• You need consistent measurements. Synthetic runs from controlled environments, so trend graphs aren't muddled by real-world variance (different devices, networks, etc.).

Limitations of synthetic monitoring

Synthetic isn't a complete observability solution. Be honest about its gaps:

• Doesn't capture real-world variance. Synthetic checks run from data centers on fast networks. Real users hit your service from coffee-shop WiFi, congested 4G, and old browsers.
• Limited to what you script. A synthetic check finds the issues you anticipated. Edge cases real users discover (specific browser bug, unusual input) won't be caught unless explicitly modeled.
• Cost scales with check frequency × locations. 1-minute checks from 10 locations = 14,400 checks/day per URL. Pricing models reflect this.
• Can be noisy without good thresholds. Naive alerting (one failure = page) creates fatigue. Mature setups require multiple consecutive failures or majority-of-locations-failing.
• Browser checks consume more resources. Real Chromium browser checks cost more than HTTP-only checks; balance frequency against cost.

Synthetic monitoring with LoadFocus

LoadFocus offers synthetic monitoring across the three main check types:

• Page speed monitoring. Real Chromium browser checks with full Lighthouse audits, Core Web Vitals tracking, and budget-based regression alerts. Run from 25+ cloud regions on schedules from every minute.
• API monitoring. HTTP/REST endpoint checks with assertion-based validation on status code, response body, and timing. Multi-step request chaining via k6 scripts.
• Load testing. Beyond synthetic monitoring of normal-traffic conditions, LoadFocus runs simulated traffic at chosen concurrency to test capacity — combining the benefits of synthetic monitoring with stress testing.

The platform integrates with Slack, PagerDuty, email, and webhooks for alert routing, and provides a CLI + GitHub Action for embedding synthetic checks in CI/CD pipelines. AI-generated waterfall analysis explains why a check is slow, surfacing optimization suggestions automatically.

FAQ: Synthetic monitoring

How is synthetic monitoring different from APM?

APM (Application Performance Monitoring) is typically agent-based and observes the inside of your application — code execution, database queries, function timing. Synthetic monitoring observes from the outside — what a user sees. APM and synthetic complement each other; many teams use both.

How often should synthetic checks run?

Critical user-facing services: every 1 minute. Internal APIs and lower-priority paths: every 5-15 minutes. Background jobs and long-running tasks: every 30 minutes to 1 hour. Higher frequency = faster detection but higher cost.

From how many locations should I monitor?

At minimum 3 (one per major region — Americas, EMEA, APAC). For global services, 5-10 locations covers most regional issues. More than 10 locations adds cost without proportional value unless you have specific country-level SLA requirements.

Should synthetic monitoring replace RUM?

No — they complement each other. Use synthetic for proactive 24/7 SLA monitoring; use RUM for understanding actual user experience and catching edge cases. Mature monitoring stacks include both.

What's the difference between synthetic monitoring and load testing?

Synthetic monitoring runs single-user checks at intervals to verify the system is working. Load testing simulates many concurrent users to verify the system can handle scale. Both are forms of proactive testing but answer different questions: "is it working" vs "will it hold up under traffic".

Can synthetic monitoring detect security issues?

Limited. Synthetic monitoring detects availability and performance issues. For security monitoring (vulnerability scanning, intrusion detection, WAF event analysis), dedicated tools (Sucuri, Cloudflare Security, security-focused SIEM) are better-fit.

Try LoadFocus synthetic monitoring free

If you're evaluating synthetic monitoring tools, LoadFocus offers page speed monitoring, API monitoring, and load testing on one platform with a no-credit-card free tier. Sign up at loadfocus.com/signup to set up your first synthetic check in under 5 minutes — multi-region, with assertions, alerts, and AI-generated analysis included on all plans.