A deployment passes every health check, then p99 latency between two regions climbs and nobody can say why. The logs show timeouts, the cloud console shows green. The network between your services, whether it is VPC peering, a transit gateway or the public internet between a CDN edge and your origin, is the part you do not own and cannot read from a dashboard. A traceroute exposes it hop by hop: which router, which network, and where the delay begins.
A visual traceroute turns that list of hops into something a team can read during an incident: every hop on a map, with its latency, jitter, packet loss and the ASN that owns it. Run from several sources, it shows whether users in Frankfurt and users in São Paulo reach the same edge, whether DNS sends them to the right region, and whether the path changed after your last release. Export it, attach it to the ticket, and stop debating whether the network is to blame.
Validate a deployment from where your users are
After deploying to a new region, do not check only from your CI runner. Trace to the new endpoint from Falkenstein, Gravelines and a Globalping probe close to your users. DNS first: does the name resolve to the address you expect in that region, or does anycast or GeoDNS send traffic elsewhere? The path next: how many ASNs sit between the probe and your provider's network, and what does the last hop cost? A path that ends in the wrong region, or a first hop inside your provider 40 ms further than expected, is a routing or DNS problem, not an application bug. If the trace ends in asterisks, retry in TCP on port 443: many load balancers filter ICMP but answer on the port they serve.
Tell a real problem from a router that ignores you
Routers rate-limit the ICMP replies that traceroute relies on, so an intermediate hop showing 50% loss while the destination shows 0% is cosmetic: the router forwards your packets and merely deprioritises its own replies. Real loss starts at one hop and persists to the destination. Latency reads the same way: a hop at 200 ms followed by hops at 20 ms is a slow control plane, not a slow path. Prefer jitter to the average: a link averaging 30 ms with 25 ms of jitter hurts a gRPC call with a tight timeout more than a stable 60 ms. Watch the ASN column: when the delay jumps exactly where the ASN changes, the problem sits at the handoff between two networks, the one thing you can escalate with evidence.
Put the network under monitoring like everything else
A route that changes is a leading indicator: a transit provider failing over, a CDN moving you to another point of presence, a BGP change upstream. Schedule a trace toward each critical endpoint, such as your origin, a database endpoint in another region or a third-party API, and set alerts on latency, packet loss and route change. When an alert fires, open the previous and the new trace side by side to see whether an 80 ms regression came from your own release or from a new transit path. Through the API, run a trace as a post-deployment step and compare the destination and the last-hop latency against your own thresholds. Export CSV or JSON for your incident tooling, PDF for the postmortem.
Reading a trace: a cross-region call that turned slow
A teaching example, not a customer measurement. A service in Frankfurt calls an API in Virginia. Hops 1 to 5 stay inside the cloud provider's network at 1 to 3 ms. At hop 6 the ASN changes to a transit carrier and latency reads 12 ms; hop 7 reads 95 ms, and every later hop stays near 95 ms, with no loss. Because the jump persists to the end it is real, and 90 ms is simply the transatlantic crossing. A second trace from a Globalping probe in New York reaches the target in 8 ms: the API is healthy; the Frankfurt service is calling the wrong region. Route the call to the European replica or budget for it. Had the hops after 7 dropped back to 12 ms, the spike would have been router noise, not a path problem.
Tools that complete the picture
Ping over a minute gives you jitter and loss without the hop detail, a quick way to confirm a regression before tracing. DNS Lookup shows which address each resolver returns, the first thing to check when a region seems to vanish. HTTP/SSL Check follows redirects and reads the certificate the way a client does, catching expired or misnamed certificates a health check may miss. Port Check confirms a firewall rule from outside. BGP Viewer tells you which ASN announces the prefix your traffic ends in.
Frequently asked questions
- Can I run a traceroute from a CI pipeline?
- Yes, through the API, available on the Pro and Business plans. Call it after a deployment to trace toward the new endpoint from the source you choose, then compare the hops, latency and destination address it returns with what you expect, in your own script. The result is the same JSON you can download from the interface, so it attaches cleanly to a deployment report or an incident.
- My trace ends in asterisks before the load balancer. Is the service down?
- Not necessarily. Many load balancers and cloud edges drop ICMP and ignore UDP probes, so the trace goes silent even though HTTPS works. Run it again in TCP mode on the port you actually serve, and confirm with HTTP/SSL Check. If the TCP trace reaches the destination and the HTTP check answers, the service is fine and the asterisks are filtering, not an outage.
- How do I know whether a latency problem is mine or my provider's?
- Look at where the delay first appears and whether it persists. If it starts inside your provider's ASN and stays up to the destination, the issue is in their network or at their peering. If it appears exactly where the ASN changes, it is a handoff between two operators. Run the same trace from a second source: two sources agreeing on the same hop is strong evidence to attach to your ticket.