Real user monitoring tells you when something is broken — but only after someone hits it. By the time the support inbox lights up, the issue has been live for minutes. Synthetic monitoring fills that gap. Synthetic checks run on a schedule, simulate user behavior against the actual production stack, and surface failures regardless of whether real traffic happens to be hitting the broken path.
The pattern is decades old. What has changed is the sophistication: modern synthetics run full browser sessions, validate complex flows, and integrate with the same observability stack as the application itself. This guide is about what to probe, how often, and where most teams get the strategy wrong.
What Synthetic Monitoring Is For
Three categories of problems are detected primarily by synthetic monitoring:
- Low-traffic critical paths. The login page during off-peak hours. The yearly tax export endpoint. Paths that real users hit rarely but absolutely must work when they do.
- Externally visible regressions. SSL certificates expiring, third-party CDNs degrading, DNS misconfigurations after a deploy. These show up downstream of your code where internal metrics are quiet.
- End-to-end correctness. A login that succeeds, the API that follows, and the data that comes back. Internal metrics can each be green while the end-to-end flow is broken (auth returns a token, but the token is invalid).
Synthetic monitoring is not a replacement for real user monitoring or for system metrics. It complements them by catching the failures those tools miss.
Types of Synthetic Checks
Four layers, increasing in cost and coverage:
Ping / TCP checks. "Can I reach this host on this port?" Cheap, fast, low-signal. Useful as a fast canary but rarely tells you anything subtle.
HTTP checks. "Does GET /healthz return 200 with the expected body?" The most common synthetic check. Catches application-level outages and most network problems.
API workflow checks. Multi-step: log in, create a resource, fetch it, delete it. Catches issues that single-call checks miss — broken auth, schema mismatches, data layer problems.
Browser checks. A headless browser visits the site, runs JavaScript, clicks through a real flow. Slowest and most expensive, but the only way to catch issues that exist purely in the rendered frontend (a CDN serving a stale bundle, a third-party script breaking the page).
A mature setup uses all four. The cheaper ones run frequently across many endpoints; the expensive ones run less often on the most important flows.
Where to Run Probes From
Location matters more than most teams expect.
- Same network as the application. Inexpensive, but only catches application failures — not network or CDN issues between users and the app.
- Different cloud region. Tests the network path. Catches DNS, CDN, and routing problems.
- Different cloud provider. Tests independence from your provider. If AWS east goes down and your probes are also in AWS east, your synthetic monitoring goes down with the application.
- End-user-style locations. Datacenters near major user populations — or actual residential ISPs through services like Catchpoint and ThousandEyes. The most realistic, the most expensive.
For a typical SaaS product, three or four locations across different providers is enough. The goal is not coverage of every city; it is the ability to distinguish "the app is down" from "one region's path to the app is down."
Probe Frequency
Higher frequency catches outages faster but costs more and increases noise.
A pragmatic frequency tier:
- Critical paths (homepage, login, checkout): every 1 minute
- Important workflows (signup, password reset, API key creation): every 5 minutes
- Catalog of endpoints, less-critical pages: every 10–15 minutes
- Compliance-driven checks (SSL expiry, DNS): every hour
Going below 1 minute is rarely worth it. By the time a sub-minute outage is detectable, real-user monitoring or system metrics have usually noticed.
Avoiding the Worst Failure Modes
Three mistakes show up in nearly every team's first synthetic monitoring setup.
Probing inside the perimeter. A check that runs from the same VPC as the application skips DNS, the load balancer, and most network paths. It will be green during an outage that user traffic cannot reach the app. Always run at least one probe from outside the perimeter.
Authoring brittle checks. A check that asserts a specific HTML class or button text breaks when the marketing team changes a header. Brittle checks lead to alert fatigue and disabled checks. Assert structural facts ("a login form exists") not cosmetic ones ("the login button has the text 'Sign in'").
Alerting on single failures. Probes fail for transient reasons — packet loss, momentary slow DNS, your provider's regional blip. Most synthetic platforms support "alert after N consecutive failures" or "alert when M of last N failed." Use it. The cost is detection delay measured in minutes; the benefit is avoiding daily false alerts.
Synthetic vs Health Checks
A frequent confusion: "isn't this just a health check?"
Health checks are for the load balancer and the orchestrator — they decide whether to route traffic to an instance. Synthetic checks are for humans — they decide whether to wake someone up.
They overlap, but the asymmetry is important:
- A health check that depends on the database goes red during a database outage. Every instance is removed from rotation. The site goes down. Health checks should be cheap and self-contained.
- A synthetic check that depends on the database should go red during a database outage. That is what you want to know.
Never wire your load balancer's health endpoint to your synthetic check infrastructure. They have different jobs.
Validation Beyond "Status Code 200"
The value of a synthetic check is in what it asserts. A check that only validates 200 catches a small fraction of failures.
Stronger assertions:
- Response shape. The JSON has the expected keys. Schema-driven validation catches API contract regressions.
- Response content. A known sentinel value appears in the body. Catches stale caches and CDN misconfigurations.
- Response time. Threshold-based — alert if the check is slow even when the status is 200. Often the first signal of a degraded backend.
- Multi-step state. After creating a resource, fetching it returns the same data. Catches data layer corruption that single-call checks miss.
Each assertion adds complexity. The tradeoff is real: a richer check catches more, but takes longer to author and to keep current.
Integration with the Rest of Observability
Synthetic check results belong in the same place as the rest of your data. Pipe them to your metrics backend as time series — synthetic.latency, synthetic.success_rate — and alert through the same routing as system alerts. Most modern synthetic platforms (Datadog, Grafana Cloud, Checkly) expose this as a primary feature.
The payoff is correlation. When a synthetic alert fires, the on-call sees the latency spike on the same dashboard as the deploy that caused it. Without integration, synthetics become a separate UI nobody opens.
A Starting Setup
For a service running in production with no synthetics today:
- One HTTP check per environment against
/healthz, every 1 minute, from outside the perimeter. - One workflow check against the most-used login or signup flow, every 5 minutes.
- SSL expiry check on the public certificates, hourly.
- All three feed metrics and alerts into the existing observability stack.
This is one afternoon of setup and catches the majority of customer-visible regressions before users do.
Deciding which synthetic checks are worth running on your stack? We help teams design synthetic monitoring that catches the failures real users would otherwise report first. scopeforged.com
