Synthetic Monitoring
Synthetic monitoring runs scheduled checks against a service from chosen locations. It tells you whether a defined endpoint or user journey works before a customer reports a failure.
itObservability and performance | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Synthetic Monitoring
Synthetic monitoring is a scheduled attempt to do one small, important thing before a customer has to discover that it stopped working. A probe asks an endpoint for an answer, follows an API workflow, or drives a browser through a journey. It records whether the expected interaction happened and how long it took. The arrangement is not glamorous. Neither is discovering a broken sign-in path from a customer email.
The central idea is the check contract: target, probe location, schedule, timeout, assertion, alert owner, and first investigation step. That list exists because a URL is not a promise. A health endpoint might reply while the response is wrong. A login page might load while sign-in is broken. The assertion has to prove the behavior that deserves an alert, which is annoyingly more specific than asking whether the internet is generally in a good mood.
A probe also changes the evidence. A public probe asks whether the public target works from that external location. A private probe asks whether it works from the network where that probe runs. Neither one speaks for every device, network, identity state, cache, or user journey. This is controlled evidence, not a tiny oracle with a clipboard.
Choose the least complicated check that proves the promise. HTTP, DNS, TCP, ICMP, TLS, and gRPC checks can answer narrow protocol questions. A multistep check carries state through a sequence of requests. A browser check drives an automated interaction. Each step up can prove more behavior, but also brings more state and more ways for a check to become brittle. The surprise is that a deeper check is not automatically a better one; it is only better when that extra behavior is the thing you are protecting.
A failed check starts an investigation. It does not announce the root cause with ceremonial authority. Put the failed assertion, location, time, and diagnostic detail in the alert, then compare it with logs, metrics, traces, and recent changes. Treat test identities and secrets as production-sensitive, avoid irreversible actions, and give any state-changing test a cleanup path.
Read the Intro for the full check path and the limits of synthetic evidence. Use Slides for the compact map of check types, locations, and decisions. Keep the Cheatsheet nearby when defining an assertion or alert. The Practice Reference turns one service promise into a check contract, and the Exercise lets you watch an assertion pass, then fail for a deliberate reason. That is a much more useful kind of reassurance.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.cloud.google.com/monitoring/uptime-checks/introduction
Supports
- Synthetic monitors periodically issue simulated requests and record success and latency
- Uptime checks can send HTTP, HTTPS, or TCP requests and validate response data
- Synthetic monitors can test login, checkout, and third-party API workflows
- Public and private uptime checks have different network boundaries
- Synthetic results include success or failure, execution time, logs, and metrics
- https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/introduction/
Supports
- Synthetic monitoring supplies an external blackbox view of applications and services
- Supported checks include ICMP, HTTP, HTTPS, DNS, TCP, traceroute, scripted k6, and browser k6 checks
- Probes collect target availability, health, and response latency data
- Each selected probe runs independently at every scheduled interval
- Public and private probes are available
- https://prometheus.io/docs/guides/multi-target-exporter/
Supports
- Blackbox probing can report success, timing phases, status, TLS state, and certificate expiry
- Prometheus can scrape an exporter probe endpoint for remote targets
- https://github.com/prometheus/blackbox_exporter
Supports
- Blackbox Exporter probes HTTP, HTTPS, DNS, TCP, ICMP, and gRPC endpoints
- Probe results include a success metric and timing metrics
- https://github.com/adriannovegil/awesome-observability
Supports
- The curated observability list includes k6 among load generators and synthetic traffic tools
- The curated observability list includes monitoring and uptime ecosystem tools
- https://grafana.com/docs/k6/latest/testing-guides/synthetic-monitoring/
Supports
- k6 can run scheduled smoke tests for continuous production monitoring
- https://www.checklyhq.com/docs/detect/synthetic-monitoring/overview/
Supports
- Checkly provides API, multistep API, browser, Playwright-suite, and agentic check types
- Checkly browser checks use Playwright
- https://docs.datadoghq.com/synthetics/
Supports
- Datadog provides browser and API test monitoring in its observability platform
- https://www.dynatrace.com/platform/synthetic-monitoring/
Supports
- Dynatrace runs scheduled synthetic tests from public and private locations
- Dynatrace combines synthetic and real-user monitoring as complementary evidence
- https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/intro-synthetic-monitoring/
Supports
- New Relic synthetic monitors run API checks and scripted browser workflows
- New Relic supports private locations for protected applications
- https://www.pingdom.com/synthetic-monitoring/
Supports
- Pingdom provides uptime, page-speed, and transaction monitoring from external locations
- https://grafana.com/docs/k6/latest/using-k6/http-requests/
Supports
- k6 scripts can issue HTTP requests
- https://grafana.com/docs/k6/latest/using-k6/checks/
Supports
- k6 checks validate conditions and report passing or failing results
