Synthetics and Uptime Checks

The idea in one sentence

Synthetic Monitoring runs scripted checks proactively from Datadog’s own global network of locations instead of waiting for real user or backend traffic to reveal a problem, and once a test fails, it feeds into the exact same monitor and notification pipeline already covered earlier in this module.

API tests: single request-response checks

An API test is a single HTTP/TCP/DNS/ICMP request-response check — for example, hitting a health-check endpoint and asserting on the status code, response time, or body content. It runs repeatedly from whichever locations you choose.

{
  "name": "Checkout health check",
  "type": "api",
  "subtype": "http",
  "config": {
    "request": {
      "method": "GET",
      "url": "https://checkout.example.com/health"
    },
    "assertions": [
      { "type": "statusCode", "operator": "is", "target": 200 },
      { "type": "responseTime", "operator": "lessThan", "target": 300 }
    ]
  },
  "locations": ["aws:ap-southeast-1", "aws:eu-west-1"]
}

Browser tests: full scripted user journeys

A Browser test runs a full scripted browser flow across multiple steps — load a page, click a login button, assert a dashboard element appears — to test a real user journey end to end. This catches things an API test physically cannot: a page can return 200 and still render a broken UI, or a flow can fail partway through even though every individual request behind it “succeeded.”

{
  "name": "Login flow",
  "type": "browser",
  "config": {
    "steps": [
      { "type": "goToUrl", "params": { "value": "https://app.example.com/login" } },
      { "type": "click", "params": { "element": "#login-button" } },
      { "type": "assertElementPresent", "params": { "element": "#dashboard" } }
    ]
  },
  "locations": ["aws:us-east-1"]
}

Same alerting pipeline, different signal source

A failing Synthetic test triggers a synthetics alert monitor — and a synthetics alert monitor uses the exact same threshold, notification, and escalation mechanics taught earlier in this module. Critical/warning thresholds, @-mentions, escalation_message, and Downtimes for planned maintenance all work identically; only the input feeding the monitor is different.

{
  "type": "synthetics alert",
  "query": "\"synthetics\" for test_public_id in (\"abc-def-ghi\") \"failure\" over \"5m\" last \"3\" check greater than 2",
  "options": {
    "thresholds": {
      "critical": 2,
      "warning": 1
    }
  },
  "message": "@slack-checkout-oncall @pagerduty-checkout-critical Checkout health check is failing from multiple locations.",
  "escalation_message": "@pagerduty-checkout-escalation Still failing, escalating."
}

Nothing about the alerting mechanics changes here. It’s the same critical/warning threshold shape from lesson 1, the same @-mention routing and escalation_message re-notify behavior from lesson 2, and the same ability to mute with a Downtime during planned maintenance. Only the signal source is different: instead of a metric query or a log search, the input is “did this scripted check pass or fail, from these locations.”

flowchart LR
  Loc1[Location: ap-southeast-1] --> Test[Synthetic test: API or Browser]
  Loc2[Location: eu-west-1] --> Test
  Test -->|pass or fail per run| History[Test result history]
  History --> Mon[synthetics alert monitor]
  Mon -->|critical/warning thresholds| Notify[Same notification/escalation pipeline as metric and composite monitors]

From Synthetic test run to alert