Synthetic Monitoring and User Journey Checks
Synthetic monitoring runs controlled requests or scripted journeys to check whether an expected outcome can be reached. A useful check does more than confirm that a page loaded: it exercises the operation users need and explains where the observed path stopped.
Start with one critical journey and its expected result. Then identify what the probe actually represents: location, network, browser, account, data, and timing. A passing check provides evidence for that path at that moment. It does not prove every user, region, permission level, or dependency is healthy.
TL;DR
- Assert a meaningful result beyond an HTTP success or visible page title.
- Keep probe health, journey failure, and unresolved observations distinct.
- Choose locations and accounts from the actual coverage question.
- Bound test data, side effects, frequency, and cleanup responsibilities.
- Verify detection and routing with approved failure exercises before relying on the check.
Quick Example
This complete Python model separates a healthy runner’s failed assertion from a probe error and an unresolved timeout. All inputs are fictional classifications, not collected telemetry.
All assertions passed locally. A separate loopback browser fixture also exercised Create demo report: the success response produced ready with three rows, and a deliberate HTTP 500 produced a failed report assertion. These checks involved no real account, external service, monitoring scheduler, location network, or alert receiver. The timeout model was not a real network-failure test.
Core Concepts
Active observation
Synthetic checks create traffic to observe a defined path. Real-user measurements observe actual sessions and can expose conditions the synthetic path misses. Combine evidence according to the question rather than treating either as complete coverage.
Symptom and diagnosis
Google SRE distinguishes black-box observations of externally visible behavior from white-box telemetry inside the system. Symptoms help identify user impact; internal evidence helps explain it. A synthetic failure is an observation requiring context, not automatic proof of a specific root cause. Monitoring distributed systems
Probe and target
The probe has its own dependencies: scheduling, runtime startup, DNS, network, credentials, clock, and result transport. If those fail, a missing or failed run cannot safely be interpreted as a successful application operation.
Define the journey as an observable contract
This table is an editorial design aid, not a universal implementation. Choose assertions that survive harmless wording or layout changes while still detecting meaningful failures. A selector tied to incidental markup can become noisy; a selector so broad that it matches an error page can miss the outage.
For asynchronous work, distinguish accepted from completed. A journey that stops at the initial response may never observe the worker, storage, or result retrieval that users depend on. Set an appropriate completion budget and record which step exceeded it.
Use accounts and data intended for testing. A journey with administrator privileges can pass while ordinary users are denied. A specially cached demo object can avoid the dependency you meant to exercise. Document those differences so the apparent coverage does not exceed the actual path.
Avoid uncontrolled consequential actions. If a journey creates records, define bounded identifiers, approved retention and cleanup, duplicate handling, and ownership. Do not send real purchases, messages, or permission changes merely because those operations appear in a user flow.
Interpret failures without flattening the evidence
A failed assertion means the observed result did not match the contract. That might reflect an application defect, stale fixture data, changed expected behavior, or a broken selector. Preserve the relevant response and stage while limiting sensitive content in screenshots and logs.
A runner-start failure or absent result can indicate the probe infrastructure is unhealthy. A request timeout can remain ambiguous: client network, server, dependency, or scheduling pressure may be involved. Label uncertainty and compare independent evidence rather than assigning every timeout to the application.
Use additional locations when they answer a real coverage question. Different regions or networks can reveal routing and edge behavior, but several probes sharing the same provider or dependency may fail together. Record shared dependencies before treating the votes as independent.
Compare synthetic symptoms with real-user reports, service metrics, traces, and dependency health. A passing synthetic check can coexist with a permission failure for another audience. A failing probe can coexist with a healthy application for ordinary users. Both observations deserve explanation.
Keep retries visible. A retry may reduce sensitivity to transient probe failures, but it also changes detection delay and can hide intermittent user-visible failures. Preserve first-attempt and final outcomes if those distinctions matter to the service objective.
Make the monitor useful to its owner
Define the owner, response urgency, routing, and first diagnostic action. A check that nobody can act on adds noise. A check that silently stopped running removes evidence while leaving a comforting dashboard tile.
Watch freshness as well as the last result. A pass from yesterday is not a pass now. Specify the expected run interval, allowed lateness, and the separate condition for missing results. Treat scheduling backlog as a probe problem until the evidence supports a broader conclusion.
Exercise a controlled failure in an approved environment and confirm the entire path from failed assertion to the intended receiver. Verify recovery and deduplication as well. The local demonstration for this article checked browser outcomes only; no live routing or notification was performed.
Review the check after application changes. Keep the journey meaningful as authentication, rendering, permissions, and asynchronous work evolve. A maintenance update should preserve the user outcome instead of merely making the script green again.
Measure the monitor’s usefulness through relevant detections, false or ambiguous failures, missed conditions, time to useful diagnosis, and operating cost. More runs are not automatically better coverage. Choose frequency and locations that improve the decision you need to make.
Best Practices
Assert the result users need
Choose the smallest journey that crosses the important boundaries and proves its declared outcome. Record what the check omits.
Preserve uncertainty
Represent runner errors, missing results, assertion failures, and unresolved timeouts distinctly. Compare independent evidence before assigning a cause.
Verify ownership and freshness
Give every check a response path and monitor its continued execution. Revisit the fixture and expectations when the product changes.
Common Mistakes
Bad: HTTP 200 proves the journey worked.
Correct: Assert the meaningful final content or state, including asynchronous completion where needed.
Bad: No new failures means the monitor is healthy.
Correct: Check whether runs are fresh and results are arriving.
Bad: A failed probe identifies the application root cause.
Correct: Preserve the failure stage and compare runner, network, application, and dependency evidence.
FAQ
How many locations should run a check?
Choose from the regions and network paths you need to represent, their shared dependencies, and the consequence of missed coverage. There is no universal count.
Should a synthetic check contribute to an SLO?
Only under a clearly defined measurement contract that represents the service objective. Synthetic observations and real-user events have different denominators and coverage.
What did the local browser check prove?
That a toy loopback journey distinguished an expected report from an intentional server error. It did not validate global availability, real authentication, alert routing, or production coverage.
Related Topics
- Monitoring — Observation methods and operating ownership.
- Actionable Alerts and Noise Reduction — Useful alert contracts and missing-data handling.
- End-to-End Testing Strategy — Journey assertions and controlled test environments.