Synthetic Monitoring
Synthetic monitoring runs scripted probes from controlled locations, detecting availability, latency, and TLS or DNS failures before users report them.
Definition
Synthetic monitoring executes scripted transactions and health checks on a schedule from external vantage points to verify that a service is reachable and behaving.
Context and scope
Applied to public endpoints, critical user journeys, and dependencies, especially where real-user telemetry is sparse or lacks coverage.
Common misconceptions
- Synthetic checks are equivalent to real-user monitoring
- A passing homepage check proves the service is healthy
- Synthetic monitoring replaces integration tests
Anti-patterns
- Probing only the home page and ignoring authentication and writes
- Running every check from one region or one network
- Alerting on each probe failure with no retry or correlation
Related concepts
Authoritative source
https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/
How synthetic monitoring works
A synthetic check is a script that behaves like a small, predictable user. It resolves DNS, opens a TLS connection, requests a page or API, and asserts on status, content, and latency. Probes run on a schedule from locations outside the service’s own network. Because the script is controlled, failures are reproducible and the measurements are comparable over time. The approach detects outages even when no real user is active, such as at night or in a new region.
What to check
Cover the journeys whose failure defines an outage: landing page, sign-in, search, checkout, and one read-only API. Add checks for certificates, DNS records, and third-party dependencies. A check that only requests a health endpoint proves the process is running, not that it can serve users. Include authentication and a harmless write where possible, and assert on meaningful content rather than a 200 status.
Locations and frequency
Probe from several regions and networks, because routing, CDN, and DNS problems are often geographic. Frequency trades cost against detection time: a one-minute interval finds outages quickly but can multiply alert noise. Use browser-based checks for rendering and API checks for speed and breadth. Compare results across locations to distinguish a global outage from a local network problem.
Alerting
A single failed probe is weak evidence. Require consecutive failures or agreement across locations before paging. Tie alerts to user-facing symptoms and SLOs rather than to every check. Route them to an owner with a runbook. For example, a TLS expiry check should warn days ahead, not at the moment the certificate expires.
Limits
Synthetic traffic is narrow and predictable. It cannot represent the diversity of devices, extensions, and network conditions that real users experience. It also adds load and maintenance. Compared to internal metrics, synthetic checks observe the path users actually take. Use it for early detection and external verification, and pair it with real-user monitoring to understand actual impact.