Synthetic Monitoring

Synthetic monitoring runs scripted tests against a website or application on a regular schedule from controlled locations, measuring availability, performance, and functional correctness. It contrasts with real user monitoring, which passively collects data from actual visitors, and the two are complementary rather than alternative.

Its principal advantage is consistency, which makes comparison meaningful. Because each test runs under identical conditions, from the same locations with the same device profile and network characteristics, changes in the results reflect changes in the site rather than changes in who happened to visit. Real user data is more representative and considerably noisier, since it mixes device types, connection quality, and geography in proportions that vary continuously.

The second advantage is coverage of what real users have not yet encountered. Synthetic tests exercise pages and journeys regardless of traffic, which means low-traffic but high-value paths are monitored as thoroughly as popular ones, and problems are detected outside business hours when few real users are present. It also allows testing before release, in staging environments where no real users exist at all.

Transaction monitoring extends the approach from measurement to functional verification. A script that completes a login, adds an item to a cart, and proceeds through checkout confirms that a critical journey actually works, not merely that the pages load. This catches failures that availability checks miss entirely, including broken integrations, expired credentials, payment gateway problems, and defects introduced by third-party changes.

Its limitation is representativeness, and this is where over-reliance causes problems. A synthetic test from a well-connected data centre on a modern device profile does not reflect the experience of a customer on a mid-range phone with a poor mobile connection. Sites monitored exclusively this way frequently report healthy performance while real users experience something considerably worse, which is why the two approaches need to be used together.

Test design determines what the monitoring is worth. Checks that only confirm a page returned a successful status code will report health while the page renders an error message or displays nothing. Assertions on the presence of expected content, on response times against thresholds, and on the successful completion of each step in a journey are what make a failure detectable. Maintaining these as the site changes is an ongoing cost that is frequently underestimated.

Location selection should reflect where customers actually are rather than where testing is convenient. Monitoring exclusively from a location near the origin infrastructure produces consistently favourable results and misses the latency that distant markets experience. Testing from each significant market, and comparing between them, frequently reveals that one region is being served substantially worse than the aggregate figures suggest.

Alerting configuration determines whether the monitoring produces action or noise. Thresholds set too tightly generate frequent alerts for transient variation, and teams that are woken repeatedly for non-issues stop responding. Requiring a failure to persist across consecutive checks or across multiple locations before alerting, and distinguishing severity so that a slow page and a failed checkout do not produce the same response, is what keeps the system credible.

Because it verifies both availability and business-critical journeys, the practice sits between performance work and operational monitoring. In practice the performance measurement is established through web performance work alongside field data, the journey scripts and alerting are operated by the IT department, and for e-commerce businesses the checkout transaction check is frequently the single most valuable monitor in the estate.