Your Uptime Monitor Looks Fine. Your Customers Disagree

A basic uptime check confirms the server returns a 200 status code, which tells you almost nothing about whether the product actually works. The database can be timing out on every write, a third-party payment processor can be down, or a recent deploy can have broken the checkout flow specifically, and a homepage ping stays green through all of it. Synthetic monitoring means scripting an actual transaction, logging in, adding an item, completing checkout, and confirming the result at every step, not just the final status code.

• Authentication: a scripted login with a dedicated test account, run from outside your infrastructure, catches an auth provider outage or a broken session cookie config.
• The core transaction: whatever action makes your product money, a checkout, a booking, a form submission, scripted end to end with assertions on the actual result, not just a 200 response.
• Every payment method separately: a payment gateway can fail for one card network or region while others work fine, so checking only one method leaves the others unmonitored.
• Search or the primary data query: confirming a known query returns a known result catches an index that silently stopped updating.

Start with whichever of these, if it broke silently for four hours, would cost the most revenue or trust, and build outward from there.

A probe that runs from inside your own cloud region will miss a DNS issue, a CDN misconfiguration, or a regional network problem that only affects customers in a specific geography. Run synthetic checks from multiple external locations, ideally matching where your actual customer base is concentrated, so a probe from a region with few customers doesn't mask a real outage affecting the region with most of them. This also catches the class of incident where your infrastructure looks perfectly healthy from the inside while being unreachable from the outside.

A single failed check from one location is often a transient network blip, not a real outage, and paging someone for every single failure trains the team to ignore the alert within a month. Require two or three consecutive failures, or failures from multiple independent locations, before paging, and route a single-location failure to a lower-priority channel for investigation rather than an immediate page. The goal is a monitor the team trusts enough to act on immediately, not one that cries wolf so often it gets muted.

Synthetic probe results are most useful when tied to the same availability target the rest of the organization already tracks. If the team has committed to three-nines availability, the allowed downtime budget is well under half a day a year¹, and every synthetic probe failure that crosses the alert threshold should count against that budget in the same dashboard leadership already looks at. This turns synthetic monitoring from an engineering-only tool into something that connects directly to a commitment the business has made to customers, especially once it sits in the same observability platform the rest of the team already checks daily.

Say a product accepts three card networks, and a routing change at the payment processor quietly breaks authorization for just one of them on a Friday afternoon. A homepage ping stays green the entire weekend, since the server is healthy and two of the three card networks still work fine. Without a probe scripted against each payment method separately, the first signal the team gets is a spike in support tickets from customers whose cards keep failing, sometimes days later, well after the trust damage is done. A synthetic probe that checks all three networks on a short interval would have caught this within minutes of the routing change, not days after it.