Synthetic monitoring and uptime checks

Metrics, logs, and traces are all generated by requests actually reaching the application. If a load balancer misconfiguration, a DNS failure, or a network outage stops requests from arriving at all, there's no traffic to generate the error metrics that would normally flag a problem — from inside the system's own telemetry, everything can look suspiciously quiet rather than obviously broken, since "no requests" and "no problems" produce identical internal signals.

Synthetic monitoring solves this by sending requests to a system from outside it, on a fixed schedule, regardless of whether any real user traffic is currently happening:

A simple version — an uptime check — just confirms the service responds at all (a 200 OK on a health endpoint). A more thorough version scripts an actual user journey (log in, add an item to a cart, check out) and verifies each step succeeds, catching a broken flow that a simple uptime check would miss entirely, since the server can be technically "up" and returning 200s while a specific critical flow is completely broken.

A synthetic check running from only one geographic location can't distinguish "the service is actually down" from "there's a network issue between that one specific location and the service" — a real, recurring source of false alarms. Running the same check from several geographically distributed locations and requiring multiple locations to agree before alerting (similar in spirit to lesson 8's multi-window alerting, applied to where a check runs instead of when) filters out single-location network flukes while still catching a genuine, global outage.

A synthetic check exercises exactly the specific paths it was written to exercise — a login-and-checkout script says nothing about the health of an account-settings page it never visits. This is a genuine limitation, not a flaw to fix by scripting every possible path (which becomes its own maintenance burden) — synthetic monitoring is deliberately narrow and high-confidence for the specific critical paths it covers, complementing real-traffic-based observability's broader but traffic-dependent coverage, not replacing it.

Synthetic checks are usually wired into the same alerting system as the symptom-based alerts from lesson 8, often at the highest severity — a failed synthetic check on a critical user journey (checkout, login) is about as close to "definitely page someone now" as an observability signal gets, precisely because it directly confirms real user impact rather than inferring it from an internal metric.