Before a customer opens a support ticket. Before the on-call phone rings at 3 AM. Before anyone posts about it. Something already went wrong, and for a while, nobody knew.
That gap, between when a problem starts and when a person notices it, is where most of the cost of a bad experience gets created. By the time an employee files a ticket or a customer abandons a transaction, the cost is already booked: in lost productivity, lost revenue, or a support queue that didn’t need to exist.
“End user experience” has become the term people reach for to describe the outcome they actually care about: can the person who needs an application reach it, and if not, does anyone find out before that person does. It’s not a new technology category. It’s a question, and most infrastructure teams can’t answer it directly. They can tell you the servers are up. They can tell you the network devices are healthy. What they usually can’t tell you, without waiting for someone to complain, is whether the path from a real location to a real application is actually working right now.
Synthetic monitoring is the mechanism that closes that gap. It’s worth being precise about what it actually is, because the term gets used loosely.
Real measurements, scheduled traffic
Synthetic monitoring deploys automated checks on a fixed schedule from known locations, and has them do what a real user would do: resolve a hostname, open a connection, load a page, submit a form. The checks are synthetic in the sense that nobody typed the request by hand. Everything the check measures is real. Latency is real. Packet loss is real. A failed DNS lookup is real. The only thing synthetic about it is the user.
That distinction matters because the alternative, waiting for real user traffic to reveal a problem, only works if someone happens to be using the application when it breaks, and only tells you about the paths real users happened to take. A synthetic check runs whether or not anyone is currently using the application, from wherever you put it, on whatever schedule you choose. It finds the 3 AM failure before the 9 AM support queue does.
A single check breaks a request into the phases where things actually go wrong:
- DNS resolution, which finds resolver problems before anything else can even start
- TCP connection, which reveals congestion or a service that isn't listening
- TLS handshake, which catches certificate and negotiation failures
- Time to first byte, which isolates application-side slowness from network slowness
- Content download, which shows bandwidth constraints on the way back
Each phase answers a different question, and a failure at any one of them looks completely different from the others. A team that only knows “the app is slow” is guessing. A team that knows time to first byte spiked while DNS and TCP stayed normal knows exactly where to look.
Location is not optional
A synthetic check run only from a cloud vantage point tells you whether the public internet can reach your application. It does not tell you whether the Wi-Fi at a specific clinic, store, or branch office can reach it, and that is usually where the actual complaint originates. End user experience, as an outcome, only means something when it’s measured from where the end user actually is: the access point, the local hardware, the WAN link, the specific location where a real person is trying to get work done or complete a purchase.
This is where geography stops being a detail and starts being the whole point. Take a real example: a DNS resolution taking 380 milliseconds from a probe in Frankfurt, versus 28 milliseconds from one in US-East, on the same hostname. From a single, centralized monitoring location, that difference is invisible; everything looks fine from home base. With checks running from where users actually are, it’s visible immediately, and it’s the difference between an assumption and an answer.
That’s the real shift synthetic monitoring makes possible: not just “is it up,” but “is it working, from here, right now, before anyone downstream has to tell us otherwise.”
What this sets up
Knowing that a check failed at the TCP phase, or that DNS is slow from one region and not another, narrows the problem down to a phase and a location. It doesn’t yet tell you which specific hop between that location and the application is responsible. That’s a different, harder question, and it’s the one hop-by-hop path testing exists to answer.
Part 2 covers that in detail: how tools like traceroute, TWAMP, and continuous path hashing turn "something is wrong somewhere on this path" into "this specific hop, right here."