Synthetic Monitoring: Proactive Performance Testing from Global Locations

Synthetic monitoring uses scripted, automated checks executed from controlled locations around the world to continuously validate that your application is available, functional, and performant — before real users encounter a problem. Unlike Real User Monitoring (RUM) which passively observes actual traffic, synthetic monitoring actively probes your system on a schedule, providing consistent baselines and immediate detection of outages or degradations.

This guide covers the types of synthetic checks, how to design multi-step transaction monitors, global checkpoint strategy, SLA validation, and how synthetic data complements Core Web Vitals and APM telemetry.

Synthetic vs. Real User Monitoring

Synthetic and RUM serve different purposes and work best together. Understanding their strengths clarifies when to use each.

Types of Synthetic Checks

1. Uptime / Availability Checks

The simplest form of synthetic monitoring. An HTTP request is sent to an endpoint, and the response is validated for status code, response time, and optionally body content. These run at high frequency (every 30-60 seconds) from multiple locations to detect outages within minutes.

# Simple availability check configuration
check:
  name: "API Health Check"
  type: http
  url: https://api.example.com/health
  method: GET
  frequency: 30s
  locations:
    - us-east-1
    - eu-west-1
    - ap-southeast-1
  assertions:
    - type: status_code
      operator: equals
      value: 200
    - type: response_time
      operator: less_than
      value: 2000  # ms
    - type: body
      operator: contains
      value: '"status":"healthy"'
  alerting:
    failure_threshold: 2  # alert after 2 consecutive failures
    channels: [pagerduty, slack-ops]

2. API Endpoint Checks

More sophisticated than simple uptime checks, API monitors validate functional behavior — correct response structure, data accuracy, authentication flows, and error handling. They test multiple endpoints in sequence, passing data between requests (e.g., create a resource, verify it exists, delete it).

3. Browser-Based Checks

Full browser synthetic checks use headless Chrome or Firefox to load pages, render content, and interact with the DOM. They measure LCP, CLS, and other Core Web Vitals from controlled environments, providing stable performance baselines free from user-device variance.

# Playwright-based browser check
# Measures page load performance and validates content
from playwright.sync_api import sync_playwright

def run_check():
    with sync_playwright() as p:
        browser = p.chromium.launch()
        context = browser.new_context(
            viewport={"width": 1920, "height": 1080},
            user_agent="SyntheticMonitor/1.0"
        )
        page = context.new_page()

        # Capture performance metrics
        page.goto("https://example.com/dashboard",
                   wait_until="networkidle")

        metrics = page.evaluate("""() => {
            const nav = performance.getEntriesByType('navigation')[0];
            const paint = performance.getEntriesByType('paint');
            const lcp = new Promise(resolve => {
                new PerformanceObserver(list => {
                    resolve(list.getEntries().pop().startTime);
                }).observe({type: 'largest-contentful-paint',
                            buffered: true});
            });
            return {
                ttfb: nav.responseStart - nav.requestStart,
                dom_interactive: nav.domInteractive,
                dom_complete: nav.domComplete,
                fcp: paint.find(e =>
                    e.name === 'first-contentful-paint')?.startTime,
            };
        }""")

        # Validate content
        assert page.title() == "Dashboard - MyApp"
        assert page.locator(".dashboard-widget").count() >= 4

        browser.close()
        return metrics

4. Multi-Step Transaction Checks

The most valuable and complex synthetic checks simulate entire user workflows: login, search for a product, add to cart, proceed to checkout, complete payment. These catch integration issues that single-endpoint checks miss — a working login page and a working checkout page do not guarantee a working login-to-checkout flow.

Designing Effective Multi-Step Checks

Multi-step transaction monitors should follow these principles:

• Mirror real user journeys: Base your scripts on actual user behavior observed through RUM or analytics. The top 5-10 user flows cover the majority of revenue-critical paths.
• Use dedicated test accounts: Synthetic checks should not pollute production data. Use clearly marked test accounts, test credit cards, and test data that can be identified and excluded from analytics.
• Assert at every step: Don't just assert the final outcome. Validate intermediate states — the search returned results, the cart has items, the payment form loaded. Step-level assertions pinpoint which part of the flow broke.
• Handle dynamic content: Pages change — promotions rotate, A/B tests run, content is personalized. Use stable selectors (data-testid attributes, ARIA roles) rather than text content or CSS classes.
• Measure step timing: Record the duration of each step independently. A slow checkout may be caused by a slow payment form load, not a slow order submission.

Global Checkpoint Strategy

The locations from which you run synthetic checks determine what performance your users experience from different regions. A strategic checkpoint distribution validates that your infrastructure — CDN, edge nodes, regional deployments — delivers acceptable performance worldwide.

Checkpoint Selection Criteria

• Match your user base: Run more frequent checks from regions where your users are concentrated. If 60% of traffic comes from Asia-Pacific, run checks every 30 seconds from APAC locations, every 5 minutes from others.
• Cover CDN edge locations: Place checkpoints near your CDN PoPs to validate edge caching, but also between PoPs to measure what users in uncached regions experience.
• Include worst-case paths: Always include at least one checkpoint from a region far from your origin servers. This reveals the maximum latency your architecture produces and validates whether your CDN strategy reaches all target markets.

SLA Validation

Synthetic monitoring is the primary tool for validating Service Level Agreements (SLAs) with customers and vendors. Because synthetic checks run from controlled environments on predictable schedules, they produce the consistent, auditable measurements that SLA contracts require.

Measuring Uptime

# SLA uptime calculation from synthetic check data

# Data: check results for the month
total_checks = 43200           # 1 check/min × 30 days
successful_checks = 43150      # 200 status, response < 2s
failed_checks = 50

# Uptime percentage
uptime = (successful_checks / total_checks) * 100
# uptime = 99.884%

# Minutes of downtime
downtime_minutes = failed_checks  # 1 check = 1 minute
# downtime_minutes = 50

# SLA breach check
sla_target = 99.95  # contractual SLA
if uptime < sla_target:
    credit_owed = calculate_sla_credit(sla_target, uptime)
    # Most SLA contracts define credit tiers:
    # 99.95% - 99.0%  → 10% credit
    # 99.0%  - 95.0%  → 25% credit
    # Below 95.0%     → 50% credit

SLA Reporting Best Practices

• Exclude planned maintenance: SLA contracts typically exclude scheduled maintenance windows. Tag maintenance periods in your synthetic data to exclude them from calculations.
• Use multi-location confirmation: A single checkpoint failure may be a network issue at the checkpoint, not a service outage. Require failures from at least 2 locations before counting against the SLA.
• Track vendor SLAs: Run synthetic checks against your third-party dependencies (payment providers, email services, CDN) to measure their actual uptime against their contractual promises.

Integrating Synthetic Data with APM

Synthetic checks become more powerful when connected to your APM system. When a synthetic check fails or degrades:

1. The synthetic alert triggers and records the failure timestamp and checkpoint location
2. The distributed trace generated by the synthetic request shows exactly where the degradation occurred
3. Error tracking captures any exceptions thrown during the synthetic request
4. Server response time metrics from the same time window provide infrastructure context

This correlation transforms a simple "check failed" alert into a complete diagnostic package — the where (checkpoint location), the what (which service or operation), and the why (the root cause visible in traces and logs).

Synthetic Monitoring Anti-Patterns

• Testing only happy paths: Synthetic checks should also validate error handling — does the 404 page load correctly? Does the API return the right error format for invalid input? Does the circuit breaker activate when a dependency is down?
• Ignoring SSL certificate expiry: Add checks that validate SSL certificate validity and alert when certificates are within 30 days of expiry. Expired certificates cause hard outages.
• Running checks too infrequently: A 5-minute check interval means a worst-case detection time of 10 minutes (one failure, then confirmation on the next check). For critical paths, 30-second intervals significantly reduce mean time to detect (MTTD).
• Not testing from user locations: Running all checks from US-East when your users are in Southeast Asia guarantees you will miss region-specific issues.
• Treating synthetic data as RUM: Synthetic checks run on fast, stable infrastructure with no real user variability. They measure server and network performance, not the experience of a user on a slow phone over a congested mobile network.

Building a Synthetic Monitoring Program

Tier 1: Critical Business Flows (check every 30s)

• Homepage load and content render
• Login / authentication flow
• Core transaction (purchase, booking, transfer)
• API health endpoints

Tier 2: Important Features (check every 2-5 min)

• Search functionality
• User profile / account management
• Notification delivery
• Third-party integration endpoints

Tier 3: Supporting Pages (check every 15-30 min)

• Marketing pages and landing pages
• Help center and documentation
• Static asset delivery
• SEO-critical page rendering

Key Takeaways

• Synthetic monitoring proactively detects issues before users report them — it does not require traffic
• Use synthetic and RUM together: synthetic measures capability, RUM measures reality
• Multi-step transaction checks catch integration issues that single-endpoint checks miss
• Place checkpoints where your users are, not just where your servers are
• Synthetic data is the foundation for contractual SLA validation and reporting
• Connect synthetic alerts to distributed traces for instant root cause identification
• Tier your checks by business criticality — critical flows every 30s, supporting pages every 15-30 min