Updated June 15, 2026

Synthetic monitoring

Run scheduled test journeys from managed regions, alert on p95 latency or error-rate regressions, and catch service degradation before customers report it.

What this workflow should produce

A recurring journey that executes on a fixed schedule from managed regions without manual intervention.
p95 and p99 latency baselines that alert when the current value drifts from the rolling average.
Error-rate and assertion signals that fire before a user reports an incident.
A release-comparison view that shows performance delta between the last deploy and the baseline.

Use case

Synthetic monitoring answers the question your on-call rotation needs answered every minute: is the service working the way users expect, right now?

The distinction from uptime monitoring is step depth. A ping or HTTP check tells you the server is responding. A synthetic journey tells you that a user can log in, navigate to the feature they pay for, and receive a correct, timely response. Many of the most damaging user-facing outages — authentication degraded but not down, search returning empty results, checkout accepting orders but not confirming them — would pass an uptime check and fail a synthetic one.

Synthetic monitoring also provides a continuous performance baseline. Because the same journey runs on a fixed schedule from the same locations, you get a natural time series: p95 on Tuesdays at 14:00 is consistently 180 ms, and the spike to 420 ms on the Tuesday after a deployment is signal, not noise.

How MaxoPerf supports it

Create a test journey — a JMeter, Taurus, or Playwright script — and schedule it to run on a cron-style interval from one or more managed regions. Each execution produces a run record with the same latency, error-rate, and assertion results as an on-demand load test.

Alerts fire when a run breaches a threshold or when the run itself fails to complete (runner error, timeout). The alert payload includes the run ID so your on-call engineer can link directly to the failing run rather than starting from scratch.

Because the scheduled check shares infrastructure and result format with load tests, you do not need a separate monitoring tool. A journey that passes the synthetic check and then gets promoted to a load test for release validation uses the same file, the same threshold language, and the same result view.

A concrete monitoring profile

An e-commerce SRE team monitors their checkout journey from three managed regions every 10 minutes:

Journey: POST /v2/auth/login → GET /v2/products/:id → POST /v2/cart/add → POST /v2/cart/checkout (4 labeled steps)
Schedule: every 10 minutes, 24 × 7, from EU-West, US-East, and AP-Southeast
Thresholds: p95 per step < 300 ms; error rate < 0.1%; assertion: checkout response contains order_id field
Alert routing: threshold breach → PagerDuty P2; run failure → PagerDuty P1 (service unreachable)
Baseline comparison: each new deploy auto-compares its first scheduled run against the previous 7-day p95 average; a regression > 20% is flagged in the deployment Slack channel

In the past year this setup caught three regressions before a customer reported them: a CDN misconfiguration (p95 EU-West jumped from 140 ms to 1.1 s), a third-party auth provider slowdown (login step error rate reached 2.3%), and a missing index on the order table after a migration (checkout p95 climbed gradually over 4 hours before breaching the alert threshold).

Practical rollout

Pick the one journey you cannot afford to miss — usually your highest-value, highest-traffic user flow. Start there; add more journeys as the discipline matures.
Author assertions, not just status checks — every step in the journey should assert something about the response body, not just the HTTP status. A 200 with no order_id is a failure.
Set realistic baselines — run the journey manually 10 times to establish a stable p95 before setting alert thresholds. Setting thresholds before you know the baseline produces alert storms.
Start with two regions — one near your largest user concentration, one geographically distant. The distant region often catches CDN and routing issues the nearby region misses.
Establish escalation paths — decide before the first alert fires who gets paged for a threshold breach vs. a run failure, and at what time of day. Synthetic monitoring is only valuable if alerts result in action.

FAQ

How often should synthetic checks run?

For critical user journeys, every 5–15 minutes is a good starting point. For lower-priority flows, hourly or every 6 hours reduces noise while still catching prolonged regressions. Start conservatively and increase frequency for paths that historically degrade quietly.

Should synthetic checks use managed or private runner locations?

Use managed locations to test from the same network perspective as your users. Add private locations when the target is behind a VPN or when you also need to measure internal latency (e.g. database response time visible only from inside the VPC). Both can run in the same scheduled check.

How is synthetic monitoring different from uptime monitoring?

Uptime monitoring checks that a URL returns a 200. Synthetic monitoring executes a multi-step journey — log in, add to cart, retrieve results — with assertions on response bodies, headers, and latency at each step. It catches degradation that a simple ping would miss: a login that succeeds but takes 8 seconds, or a search that returns 200 with an empty result set.

Related use cases

AI inference load testing
Validate LLM inference APIs under concurrent request load — measure time-to-first-token, token throughput, and cost per request to right-size GPU capacity.
Frontend browser performance testing
Load-test real browser journeys — login flows, SPAs, and media-heavy pages — measuring user-perceived latency and render performance under concurrency.
Microservices SLO validation
Confirm each service meets its latency and error-budget SLOs under realistic request concurrency before changes are promoted to production environments.

Run your first test Compare plans