Synthetic Monitoring for CDN Performance: Proactive Detection Before Users Notice

Real User Monitoring tells you what happened to your users. Synthetic monitoring tells you what will happen to them. By deploying automated probes that continuously test CDN performance from locations around the world, you detect outages, latency regressions, and configuration errors before they affect real traffic. This proactive approach is especially critical for CDN infrastructure where a misconfigured cache rule or a failing edge node can degrade performance for millions of users in a specific region without triggering traditional aggregate alerts, a gap that even comprehensive CDN observability setups can miss.

Why Synthetic Monitoring Matters for CDN

CDN performance is inherently geographic. A user in Tokyo reaches the Tokyo PoP, while a user in Frankfurt reaches the Frankfurt PoP. If the Frankfurt PoP develops a routing issue that adds 200ms of latency, only European users are affected. Aggregate metrics — global average TTFB, overall cache hit ratio — may barely move because Frankfurt traffic is a small fraction of global volume. Without synthetic probes checking from European locations, this regional degradation goes undetected until enough users complain to reach support.

Synthetic monitoring eliminates this blind spot by actively probing from every region where your users live. Each probe simulates a real user request and measures every phase of the connection: DNS resolution, TCP handshake, TLS negotiation, time to first byte, and full content download. When a probe from Frankfurt shows TTFB jumping from 30ms to 250ms while all other locations remain stable, the alert is immediate, specific, and actionable.

The second advantage of synthetic monitoring is coverage during low-traffic periods. Many CDN issues emerge during off-peak hours when operational staff may not be watching dashboards. A TLS certificate renewal failure at 2 AM, a DNS propagation issue after a zone update, or a cache purge that accidentally invalidated critical assets — all of these can be caught by synthetic probes running 24/7 regardless of actual user traffic volume.

Probe Architecture and Design

Checkpoint Distribution Strategy

Effective synthetic monitoring requires probes distributed according to your actual user base geography, not uniformly across the globe. If 70% of your traffic originates from North America and Europe, place 70% of your checkpoints in those regions. The remaining 30% should cover Asia-Pacific, South America, and other significant traffic sources.

A practical distribution for a global CDN with predominantly Western traffic uses 18-22 checkpoints:

North America (8 checkpoints):
  US East:    Virginia, New York
  US Central: Chicago, Dallas
  US West:    Los Angeles, San Francisco
  Canada:     Toronto
  Mexico:     Mexico City

Europe (6 checkpoints):
  Western:    London, Paris, Amsterdam
  Central:    Frankfurt
  Northern:   Stockholm
  Southern:   Milan

Asia-Pacific (5 checkpoints):
  East Asia:  Tokyo, Seoul
  Southeast:  Singapore
  South:      Mumbai
  Oceania:    Sydney

Other (3 checkpoints):
  South America: São Paulo
  Middle East:   Dubai
  Africa:        Johannesburg

Each checkpoint runs probes at 1-minute intervals for critical endpoints and 5-minute intervals for secondary endpoints. At 1-minute intervals, a single checkpoint generates 1,440 data points per day per probe target. With 22 checkpoints and 10 probe targets, the monitoring system processes approximately 316,800 data points daily — manageable for any time-series database.

Probe Request Design

A synthetic probe must simulate a real user request closely enough that the CDN handles it identically to production traffic. This means setting appropriate request headers (Accept, Accept-Encoding, User-Agent), following redirects, validating TLS certificates, and measuring timing at each connection phase.

# Probe configuration (YAML format)
probes:
  - name: homepage-cache-check
    url: https://example.com/
    method: GET
    headers:
      Accept: "text/html"
      Accept-Encoding: "gzip, br"
      User-Agent: "SyntheticProbe/1.0 (monitoring)"
    interval: 60s
    timeout: 10s
    assertions:
      - type: status_code
        value: 200
      - type: header
        name: "cf-cache-status"
        values: ["HIT", "DYNAMIC"]
      - type: response_time
        max_ms: 500
      - type: body_contains
        value: "<!DOCTYPE html>"
    measurements:
      - dns_ms
      - tcp_ms
      - tls_ms
      - ttfb_ms
      - download_ms
      - total_ms
      - response_size_bytes

  - name: static-asset-ttfb
    url: https://cdn.example.com/assets/app.js
    method: GET
    interval: 60s
    timeout: 5s
    assertions:
      - type: status_code
        value: 200
      - type: header
        name: "cache-control"
        contains: "max-age"
      - type: response_time
        max_ms: 200
      - type: body_hash
        algorithm: sha256
        value: "a1b2c3..."  # Known hash of current version

The body hash assertion is particularly important for CDN monitoring. It validates that the probe received the correct content, not a stale cached version, a CDN error page, or a poisoned cache entry. When the content changes (a new deployment), the expected hash updates automatically in the probe configuration as part of the deployment pipeline.

Multi-Step Transaction Monitors

Single-URL probes catch availability and latency issues but miss functional problems. A CDN may serve all static assets correctly while an edge function that handles authentication tokens or API routing fails silently. Multi-step transaction monitors simulate user workflows across multiple requests, validating that each step produces the expected result.

A typical CDN transaction monitor tests the critical user path: load the homepage (verify HTML content and cache headers), request the main JavaScript bundle (verify cache HIT and correct content hash), request an API endpoint through the CDN (verify dynamic content handling), and verify that a recently purged asset returns fresh content from origin.

Each step depends on the previous step succeeding. If the homepage returns a 503 error, the subsequent asset requests would also fail, but the root cause is the first step. Multi-step monitors report the specific step that failed, enabling faster diagnosis than a collection of independent probes that all fail simultaneously without indicating causality.

Cache-Specific Probes

CDN caching behavior deserves dedicated monitoring because cache misconfigurations are among the most common CDN issues and among the hardest to detect with aggregate metrics. A cache-specific probe sequence works as follows:

First, request a known static asset and record the cache status header. If the response is a MISS, wait 5 seconds and request again — the second request should be a HIT. If the second request is still a MISS, the CDN is not caching this asset, which may indicate a misconfigured Cache-Control header, a Vary header generating too many cache variants, or a CDN configuration excluding this content type from caching.

Second, verify cache TTL compliance. Request an asset, note the Age header value, wait 60 seconds, and request again. The new Age header should be approximately 60 seconds higher than the first. If it resets to 0, the object was evicted and re-fetched from origin prematurely, indicating an issue with the cache invalidation or TTL configuration.

Third, verify cache purge propagation. After triggering a cache purge (via API or manual action), probes from all checkpoints request the purged asset and verify it returns a MISS or new content. The time from purge request to all checkpoints seeing fresh content is the purge propagation latency — a key operational metric that should be tracked over time.

Alerting Strategy

Avoiding False Positives

Synthetic monitoring probes traverse the public internet, which introduces noise from transient network issues, ISP congestion, and DNS resolver hiccups. A single failed probe from a single checkpoint almost never indicates a CDN problem. Effective alerting requires confirmation across multiple dimensions:

Location confirmation: Require failures from at least 2-3 checkpoints in the same region before alerting. A single checkpoint failure is logged but not alerted. Two failures in the same region suggest a localized CDN issue. Three or more suggest a definite problem.

Temporal confirmation: Require consecutive failures (2-3 probe intervals) before escalating. A single failed probe followed by a successful retry indicates a transient issue. Three consecutive failures over 3 minutes indicate a persistent problem.

Baseline-relative thresholds: Instead of fixed latency thresholds (“alert if TTFB exceeds 200ms”), alert when TTFB exceeds 2x the checkpoint’s rolling 7-day p95 baseline. This automatically accounts for geographic differences — a probe from Sydney naturally has higher TTFB to US-hosted content than a probe from Virginia, so a fixed threshold either generates false positives for distant checkpoints or misses regressions for nearby ones.

Severity Classification

Map probe failures to operational severity levels that drive the correct response:

P1 (Page oncall immediately):
  - 3+ regions report complete failure (HTTP 5xx or timeout)
  - Global TTFB regression > 5x baseline sustained 5+ minutes

P2 (Notify team, 30-minute response):
  - 1 region reports complete failure
  - Cache hit ratio drops below 50% from expected > 90%
  - TTFB regression > 3x baseline in 2+ checkpoints

P3 (Queue for next business day):
  - Single checkpoint TTFB regression > 2x baseline
  - Intermittent failures (1 in 10 probes failing)
  - Cache TTL compliance drift > 10%

Informational (Dashboard only):
  - Single probe failure (auto-recovered on retry)
  - TTFB variance within 1.5x baseline
  - DNS resolution time increase < 2x

Integration with the Broader Observability Stack

Synthetic monitoring provides the external perspective that complements internal CDN metrics. When a synthetic probe from Frankfurt detects a TTFB regression, the investigation workflow correlates this external signal with internal CDN analytics — do access logs show elevated origin fetch times for the Frankfurt PoP? Are distributed traces revealing a new bottleneck in the request path? Is the PoP’s error budget being consumed at an elevated rate?

The integration between synthetic monitoring and internal observability creates a feedback loop. Synthetic probes detect the symptom (external degradation), internal metrics identify the cause (a specific PoP, cache layer, or origin issue), and distributed traces pinpoint the exact processing stage where latency increased. This combination reduces mean time to detection (MTTD) through synthetic probes and mean time to resolution (MTTR) through correlated internal data — the two dimensions that define operational excellence in CDN infrastructure.

Building synthetic monitoring into the deployment pipeline adds another dimension: pre-deployment validation. Before promoting a CDN configuration change to production, synthetic probes run against a canary deployment (a small percentage of traffic routed to the new configuration). If probes detect degradation against the canary, the deployment halts automatically. This shifts CDN failure detection from reactive (finding problems after they affect users) to preventive (catching problems before they reach production) — the ultimate goal of proactive CDN performance management.