Measure the whole path
A user does not experience DNS, routing, transport encryption, and an application as separate systems. A request either completes or it does not. Monitoring should reflect that reality.
Begin with the public name
Start a check with the same hostname and protocol a visitor uses. Confirm answers from more than one resolver, inspect the selected address, negotiate TLS, and request a real application path. Each stage should record latency and the evidence needed to explain a failure.
A local process check remains valuable, but it proves only that a process exists. It does not prove that public DNS is correct, a firewall permits the request, the certificate matches, or the return path reaches the client.
Treat latency as a distribution
A single average hides the variance users feel as stalled pages and unstable sessions. Track percentiles over time and compare observations from several networks. When a route changes, the median may remain acceptable while the tail becomes dramatically worse.
Traceroute can offer clues, but intermediate routers may handle diagnostic packets differently from application traffic. Always finish the investigation using the actual hostname, port, and protocol.
Keep the check understandable
An end-to-end probe should be simple enough that an operator can reproduce it manually. Record the resolved address, TLS name, HTTP status, response time, and observed endpoint. Good evidence shortens incidents because each result eliminates a class of possible causes.