Synthetic Monitoring: Catching Outages Before Customers Do

A synthetic probe on every API endpoint sounds thorough and produces mostly noise. Start with the handful of paths where a failure directly costs revenue or trust: login, checkout, the core action your product exists to perform.

Script each probe to actually complete the transaction, not just hit a health check endpoint, since a basic health route returning success tells you almost nothing about whether a customer can actually log in or complete a purchase.

If your SLA promises three nines of availability, you're working with an annual error budget of 8.76 hours of downtime, full stop, whether an outage shows up as a customer support ticket or not¹.

Synthetic probes are how you find out you're burning that budget in real time, from a partial degradation that never fully takes the site down but still fails a meaningful share of checkout attempts. A probe running every few minutes catches that kind of partial failure long before a slow trickle of support tickets does.

• Run probes from more than one region and require two consecutive failures before paging, so a transient network blip between the probe location and your infrastructure doesn't wake anyone up for nothing.
• Keep probe credentials and test data separate from production, and flag the probe's actions, a test purchase, a test signup, clearly so they don't pollute your real analytics or trigger real fraud checks.
• Alert on the specific step that failed, not just that the checkout probe failed, so the on-call engineer isn't starting from zero when the page fires overnight.

A synthetic probe runs the same script from the same handful of locations every time, which means it will never catch a failure specific to a particular browser, device, ISP, or geography that your actual user base includes. It also can't tell you about slowness that's still technically working, like a checkout that completes but takes noticeably longer than usual for real users on mobile networks.

Run both: synthetic probes for fast detection of hard failures on critical paths, real user monitoring for the broader picture of what your actual customers are experiencing.

A probe running from the same cloud region as your infrastructure catches an application-level failure but misses anything specific to how the wider internet reaches you: a DNS resolution problem, a CDN misconfiguration, a network path issue affecting one part of the world. Run probes from at least two or three geographically distinct locations, ideally including wherever a meaningful share of your actual customers are, so a regional problem doesn't hide behind a probe that happens to have a clean path to your servers.

Say a payment provider integration starts silently failing for one specific card network while every other transaction type keeps working. Total transaction volume barely dips, since most traffic uses other card networks, so an alert on overall error rate or total checkout volume never fires. A scripted probe that walks the full checkout flow with a specific test card on that network would catch it within minutes; a probe that only confirms the checkout page loads would not.

This is the general shape of the failures synthetic monitoring exists for: not the outage that takes everything down, but the narrower failure that's easy to miss in an aggregate metric and easy to catch with a scripted probe built around one specific real path.