HTTP monitor basics

An HTTP monitor describes one request, one set of assertions, and one frequency. It runs from one or more of our multi-region-setup edges.

request shape

name: payments-api-charge
url: https://api.example.com/v1/charges
method: POST
headers:
  Authorization: "Bearer ${secrets.PAYMENTS_TOKEN}"
  Content-Type: application/json
body: |
  { "amount_cents": 100, "currency": "usd", "idempotency_key": "df-{{run_id}}" }
timeout_ms: 5000
follow_redirects: true

A few points worth knowing:

• {{run_id}} is a per-execution UUID. Use it whenever the API insists on idempotency. The full template variable list is in variables-and-secrets.
• timeout_ms is total budget across DNS, connect, TLS, and response. Default 5000. Set it close to your real SLO so you don't paper over latency regressions.
• TLS is verified by default. For internal certs, use mtls or upload a custom CA bundle.

headers and auth

Auth headers belong in the secrets vault, not the monitor body. See authentication-headers for the supported authentication types — bearer, HMAC, OAuth2 client-credentials, API-key.

response

By default we record:

• HTTP status
• Latency (DNS, TCP, TLS, TTFB, total)
• Response size
• Response body (first 64 KB; configurable to 256 KB on Scale)

The body is the raw material for response-assertions — JSON-Schema, JSONPath, regex, or a Zod-style shape DSL.

frequency and regions

Both have their own docs — see monitor-frequency for picking 30s / 60s / 5m, and multi-region-setup for choosing edges and the quorum model.