CDN Synthetic Monitoring Setup: Probes, Checkpoints, and Alert Policies

Real-user monitoring tells you what happened. Synthetic monitoring tells you what will happen — before your users do. For CDN-reliant applications, a well-designed synthetic layer is the difference between catching a PoP failure in 45 seconds and learning about it from Twitter.

This guide covers the production setup we use for high-traffic edge deployments: probe types and assertions, checkpoint topology, and alert policies that detect real incidents without waking your on-call for transient blips. If you already have CDN monitoring and observability pipelines in place, synthetic checks are the active complement that validates them continuously.

1. Why Synthetic Monitoring Is Non-Negotiable for CDNs

CDNs abstract away origin complexity, but they introduce new failure modes: stale cache, failed tiered shielding, TLS certificate rotation errors, Anycast routing anomalies, and PoP-specific latency regressions. Passive logs and RUM will eventually surface these, but by then the impact has spread.

Synthetic probes solve three problems that passive monitoring cannot:

• Proactive validation of cache behavior. A probe can assert that x-cache: HIT is returned for static assets and that age increments correctly. RUM cannot reliably distinguish a HIT from a MISS.
• Geographic coverage independent of traffic. Low-traffic regions like Johannesburg or Santiago may have no RUM samples for minutes at a time, yet serve critical users. Synthetics guarantee coverage.
• Consistent baselines for performance budgets. By running the same request from the same checkpoint every 60 seconds, you can track CDN performance metrics like TTFB, TLS handshake, and download time with statistical rigor.

2. Probe Types: What to Measure and How

Not all probes are equal. Choosing the right probe type determines cost, frequency, and signal quality. Most mature setups use a layered combination:

HTTP / API Probes (High Frequency)

These are lightweight, headless HTTP clients that execute every 30-60 seconds. They are ideal for availability, cache validation, and header correctness. Configure them to follow redirects, validate certificates, and capture detailed timing phases: DNS, TCP, TLS, TTFB, and content transfer.

Key assertions for CDN probes:

• Status code is 200 (or 304 for revalidation)
• Response header cf-cache-status or x-cache matches expected HIT/MISS pattern
• TLS certificate expires in >14 days and CN/SAN matches
• TTFB < p95 baseline + 30% (per checkpoint)
• Body contains expected string or checksum for cache poisoning detection

Browser Probes (Hourly or On-Demand)

Browser probes run a full Chromium instance via Playwright or WebDriver. They load the page, execute JavaScript, and collect Web Vitals, filmstrip, and waterfall data. Use them at 5-15 minute intervals for critical user journeys — homepage, product detail, checkout API — not for every asset.

For a deeper look at how these probes interact with origin shielding and edge logic, see our CDN security guide on validating WAF and bot rules without triggering them in synthetics.

Multi-Step and Transaction Probes

For dynamic acceleration and CDN SSL/TLS configuration validation, chain probes: resolve DNS → establish TLS 1.3 → fetch HTML → fetch 3 static assets with cache-busted URLs. This exposes failures in HTTP/3 negotiation or 0-RTT replay that single-request probes miss.

3. Checkpoint Strategy: Where and How Many

A checkpoint is a vantage point — a city, cloud region, or ISP network — from which probes originate. The goal is not maximum coverage, but representative coverage that maps to your traffic and PoP topology.

Mapping Checkpoints to PoPs

Start by exporting your CDN's PoP list and Anycast assignments. For CloudFront, Fastly, or Cloudflare, map each probe location to the PoP it will naturally hit via BGP. If you use CDN HTTP/2, HTTP/3 and QUIC with Anycast, verify that checkpoints in the same region actually land on different PoPs — otherwise you are testing the same edge twice.

Recommended baseline distribution for a global audience:

• North America: Ashburn (VA), Dallas, San Jose — covers east, central, west and validates inland vs. coastal routing.
• Europe: Dublin, Frankfurt — tests both Atlantic edge and central EU shield.
• Asia-Pacific: Tokyo, Singapore, Sydney — captures Japan/Korea, Southeast Asia, and Oceania latencies.
• South America & Africa: São Paulo, Johannesburg — low traffic but high business impact if degraded.

Public vs. Private Checkpoints

Public checkpoints (Datadog, Checkly, Catchpoint, ThousandEyes) are easy to deploy and share IP ranges you can allowlist. Private checkpoints — small VMs in VPCs or colo — are essential if you need to test authenticated origins, internal headers, or WAF bypass tokens that you cannot expose to third-party IPs. A hybrid model works best: 80% public for breadth, 20% private for depth.

4. Alert Policies That Actually Page Correctly

The most common failure in synthetic monitoring is not missing an outage — it is paging too often. Alert policies must balance sensitivity (mean time to detect) with specificity (false positive rate).

The Multi-Location Confirmation Rule

Never alert on a single checkpoint failure. Require at least 2 of 5 or 3 of 8 checkpoints to fail within a 2-3 minute window before triggering a page. This filters transient packet loss, single-PoP blips, and checkpoint host issues. For performance alerts (latency degradation), require the same threshold to exceed baseline for 5 consecutive minutes.

Two-Tier Alert Severity

Baseline-Driven Thresholds

Static thresholds like “TTFB < 200ms” fail across geographies. A Tokyo checkpoint will always be slower from a US origin than Ashburn. Instead, compute per-checkpoint baselines using a 7-day rolling p50/p95 and alert on deviation. For example: alert if 5-minute p95 TTFB exceeds 7-day p95 by 40% or exceeds an absolute ceiling (e.g., 900ms), whichever is higher.

Include burn-rate logic for SLOs: if your error budget is 0.1% monthly, a 2% error rate for 5 minutes burns 1.4% of the budget — page. A 0.5% error rate for the same window burns 0.35% — ticket only.

5. Reference Implementation: From Probe to Page

Below is a production-ready example using Checkly-style YAML and a Terraform alert policy. It validates cache HIT for a static asset, measures TTFB per phase, and pages only on multi-location confirmation.

# checkly.config.yml — HTTP probe for CDN cache validation
checks:
  - name: "cdn-static-asset-hit"
    activated: true
    frequency: 1m
    locations: ["us-east-1", "eu-west-1", "ap-northeast-1", "sa-east-1"]
    request:
      url: "https://cdn.example.com/assets/app.7a3f.css"
      method: GET
      headers:
        "Accept-Encoding": "gzip, br"
        "User-Agent": "FlyFish-Synthetic/1.0"
      assertions:
        - "statusCode == 200"
        - "headers['x-cache'] contains 'HIT'"
        - "headers['age'] > 0"
        - "responseTime < 800"
        - "body contains '/* flyfish:css-v7a3f */'"
        - "tls.certificate.expiry > 14d"

# Terraform — alert policy with multi-location confirmation
resource "checkly_alert_channel" "pagerduty_cdn" {
  pagerduty {
    account = "flyfish-nwa"
    service_key = var.pd_service_key
    send_failure = true
    send_recovery = true
  }
}

resource "checkly_check_alert" "cdn_p1" {
  check_ids = [checkly_check.cdn_static.id]
  alert_settings {
    escalation_type = "RUN_BASED"
    run_based_escalation {
      failed_run_threshold = 2  # 2 consecutive failures
    }
    reminders { amount = 2 interval = 5 }
    parallel_run_failure_threshold = 2 # 2+ locations
  }
}

For cache MISS validation, duplicate the check with a cache-busted URL (?synthetic=miss-<timestamp>) and assert x-cache: MISS and age: 0. This ensures your origin and shield are reachable even when the edge is healthy — a critical distinction during origin outages where HITs mask failures.

6. Operational Best Practices

• Version your checks. Store probe definitions in Git, review changes like code, and deploy via CI. A bad assertion can page the entire org.
• Tag probes by service and PoP. Use labels like service:checkout, pop:iad, tier:p1 so dashboards and alerts can be filtered during incidents.
• Correlate with RUM and logs. Push synthetic metrics to the same observability backend as RUM. When both degrade, it is a CDN issue; when only RUM degrades, it is likely client or ISP specific.
• Test purges and deploys. Trigger a synthetic run immediately after a cache purge or edge config deploy and block the pipeline if assertions fail. This catches bad invalidations before users do.
• Rotate probe credentials. If probes use tokens to bypass WAF, rotate them quarterly and store in a secrets manager — never hardcode.
• Audit checkpoint IPs quarterly. Cloud providers recycle IPs; an allowlist that drifts will cause false 403s that look like outages.

When done right, synthetic monitoring becomes the fastest feedback loop in your CDN operations — faster than logs, faster than RUM, and far more deterministic. Start with 4-5 high-value HTTP probes and one browser journey, nail the alert policy, then expand. The goal is not more monitors, but monitors that earn trust when they page.