Synthetic Monitoring

From the left sidebar, open Synthetic Monitoring → Add New Test. The Synthetics List view also exposes quick filters (Status, Test Type, Location, Response Type) so you can later find and manage monitors at scale.

Pick the protocol you need to test. If you don’t specify one, it defaults to HTTP. Typical use cases:

• HTTP: Ping a web/API endpoint; validate status code, response time, and (optionally) content presence.
• SSL: Check TLS/SSL certificate validity/expiration for a host.
• DNS: Resolve a record and measure response/accuracy.
• WebSocket: Open a socket and exchange a message.
• UDP / ICMP / TCP: Validate basic network reachability/latency/packet loss outside the application layer.
• gRPC: Call a gRPC endpoint and track latency/errors.

Tip: Start with the simplest check that proves your SLI. For an API, that’s usually: HTTP 200 AND response time < threshold. Add deeper checks later.

Fill out:

• Name: A human-readable label (e.g., Landing page – us-east or Checkout API), so teams instantly recognize what failed.
• Environment: Tag monitors per environment (prod/stage/dev) to scope dashboards and notifications.
• Additional Tags: Freeform labels for ownership/routing (e.g., team:payments, service:web).
• Test Type: Choose Single-step API tests here. (Multistep and Browser tests are separate flows.)
• HTTP Method & URL (for HTTP): Select the verb (GET/POST/DELETE…) and enter the endpoint URL. Use the same URL structure you’d give a customer or external integration.

Good practice: model monitors after real traffic. If customers call /api/v1/products?category=shoes, test that exact path with any required headers or tokens (never test an internal endpoint if the user-visible one is different).

Assertions declare exactly what success means. The UI lets you stack rules like:

• When the Status code is 200
• AND When the Response time is less than 500 ms

Design tips

• Choose thresholds that reflect your SLOs (e.g., “p95 < 300ms” might translate to a conservative <500ms per run, depending on variability).
• Model AND conditions sparingly; excessive rules increase false positives in noisy networks.

Pick one or more regions where the monitor should run. Start with a single region to validate your setup, then expand. Geographies often surface hidden problems such as CDN routing, DNS geo, or regional WAF rules.

If your endpoints are restricted, whitelist the synthetic agent IPs (table below). This is required for private allow-lists and geofenced services.

Decide how often to run. Higher frequencies catch issues earlier but cost more and can generate more traffic.

Frequency guidance:

• Critical APIs: 30–60s.
• Non-critical: 1–5 min.
• Heavy endpoints: Start at 5–10 min, then tune down if needed.

Select your notification source(s) (Slack, Email, Opsgenie, PagerDuty), add recipients, and fine-tune behavior:

• Re-notify every n minutes to keep incidents visible.
• Trigger after n monitor failures across all locations to dampen one-off blips.

Click Create Monitor to save.