A Checklist for Synthetic Monitoring That Actually Catches Outages Early

Start with the handful of flows that would actually hurt if they broke: signup, login, checkout, whatever the core action of your product is. Resist the urge to synthetically monitor every page. A probe on your marketing homepage tells you less than a probe on your checkout flow, but it's tempting to add anyway because it's easy. Every additional probe is something someone has to maintain when the UI changes, so each one should earn its place.

A probe running from the same cloud region as your servers will miss latency and routing problems that a customer three regions away experiences every day. If you have customers in multiple geographies, run probes from multiple locations, not just your own infrastructure's home region. This is also the only reliable way to catch a DNS or CDN misconfiguration that's invisible from inside your own network but very visible to an actual customer.

A common mistake is picking an alert threshold that sounds reasonable, three seconds, five seconds, without checking what your probe's normal response time actually looks like. Pull two weeks of probe history first, and set the threshold a meaningful distance above your actual p95, not an arbitrary round number. A threshold set too tight fires constantly and gets ignored; a threshold set too loose misses the slow degradation that precedes a full outage.

Before trusting a synthetic monitoring setup, confirm each of these:

• Every probe covers a transaction, not just a page load, since a page that loads but a form that silently fails is the failure mode that hurts customers most.
• Probes run from at least two geographic locations if you have customers outside your primary server region.
• Alert thresholds are set from real historical data, not a guess.
• Alerts route to whoever is actually on call, tested with a real page, not assumed to work.
• Each probe has an owner who updates its script when the underlying flow changes, so it doesn't start failing for reasons that have nothing to do with an actual outage.

The most common failure isn't a missing probe, it's a stale one. A UI change breaks a login probe's selector, the probe starts failing constantly for a reason that has nothing to do with an outage, someone mutes the alert to stop the noise, and it stays muted for months. Give every probe a named owner, review the list quarterly, and treat a probe that's been failing for more than a day as either a real incident or a maintenance task, never as something to just silence and forget.

How aggressively you invest in synthetic coverage should track your own uptime target, not an arbitrary sense of thoroughness. A team promising 99.9 percent availability has a downtime budget measured in hours a year, not days¹. A probe that only checks infrequently could let an outage burn through a meaningful chunk of that budget before anyone notices it. If your target is looser, checking less often might genuinely be enough, and spending engineering time tightening probe frequency further wouldn't buy you anything real. Decide the frequency from the budget, not the other way around.

Say a payment provider's SDK ships an update that silently swallows a specific card-decline error instead of surfacing it, so checkout appears to load fine but a subset of real transactions fail with no visible error on the page. A page-load probe would never catch this, since the page renders normally. A transaction probe that actually completes a test purchase with a known test card, and checks for a specific success confirmation rather than just an HTTP 200, would fail immediately. This is the concrete difference between monitoring that a page loads and monitoring that a transaction works, and it's usually the second one that matches what a customer actually experiences.