Monitoring
Designing synthetic monitoring for critical customer journeys
Synthetic monitoring is most useful when it represents a small set of customer journeys that would be expensive to miss. The goal is not to automate every screen; it is to detect meaningful service failure early, with a signal an on-call team can act on.
Monitor an outcome, not a page
A login page loading successfully does not prove a customer can sign in. A product page loading does not prove checkout works. Define the outcome at the end of the journey, then identify the smallest realistic path that proves it.
Start with a handful of journeys: sign-in, a core search or transaction, a high-value integration, and any path where failure would create an immediate support or revenue problem.
Engineer for repeatability
A monitoring check is production software. It needs stable selectors, explicit waits, safe credentials, controlled data, timeouts, useful diagnostics, and a recovery path for expected state changes.
Avoid checks that create irreversible production data or depend on an unpredictable shared account. A false alert erodes trust; a reliable failure screenshot, trace, and dependency context speeds response.
- Test-account lifecycle and least privilege
- Data creation, reservation, and cleanup
- Screenshots, traces, and correlation identifiers
- Thresholds aligned to customer impact rather than arbitrary timings
Turn alerts into action
Alert only when a team can do something with the signal. Link each check to an owner, runbook, severity, and an explanation of what has actually been proved to fail.
Review checks after incidents and product changes. Synthetic monitoring should evolve with the service, not become an unowned set of brittle scripts.
When this is not the right approach
Synthetic checks do not replace real-user monitoring, logs, traces, or business metrics. Use them to provide proactive evidence for a defined journey, then combine them with the wider operational picture.
Apply it to your context