Skip to main content
Monitoring as Code: Learn more about the Traceroute Monitor Construct.

​
What are Traceroute Monitors?

Traceroute monitors map the network path between a Checkly location and your target host, recording every router hop along the way and measuring per-hop latency and packet loss. Typical use cases include:
  • Detecting routing anomalies or unexpected path changes between Checkly locations and your infrastructure
  • Identifying which network segment is responsible for latency spikes or packet loss
  • Verifying that the destination is reachable end-to-end, beyond just confirming that a port accepts connections
  • Continuously monitoring path stability across regions over time

​
How do Traceroute Monitors work?

A Traceroute monitor executes the following steps on each run:
  1. Hostname resolution: If a hostname is provided, Checkly resolves it to an IP address before sending any probes
  2. Probe execution: The runner sends probe packets using the configured protocol (TCP by default). Each probe carries a progressively higher TTL, so each router on the path in turn drops the probe whose TTL expires there and responds with an ICMP Time Exceeded message
  3. Hop collection: RTT statistics (avg, min, max, stddev) and packet loss are collected for each router hop along the path
  4. Destination detection: When the destination host responds directly, the trace is complete and destinationReached is set to true
  5. Assertion evaluation: Configured assertions are evaluated against the results — including final-hop latency, total hop count, and last-hop packet loss

​
Probe protocols

The default port is protocol-dependent everywhere — web UI, CLI, and API: 443 for TCP and 33434 for UDP/SCTP. 33434 is a high, typically-closed port: UDP and SCTP arrival is only confirmed when the destination returns an ICMP Destination Unreachable, which requires the probed port to be closed. Avoid setting an open port (like 443) for UDP/SCTP probes — it would never confirm arrival.

​
Traceroute Monitor Results

Select a specific check run to inspect its results:
  • Summary: Shows the target hostname, resolved IP, monitor state (passed, degraded, or failed), total hop count, and whether the destination was reached
  • Error details: If the trace failed — due to a DNS resolution error, an unreachable network, or assertion failures — the error message is shown here
  • Hop-by-hop table: Each hop shows:
    • Hop number and primary IP address, with reverse-DNS hostname when PTR lookup is enabled
    • ASN, organization name, and country
    • AWS region and service (where applicable)
    • Probes sent and received, plus packet loss percentage
    • RTT statistics: last, avg, best, worst, and stddev in milliseconds
  • Final-hop latency: RTT statistics for the destination hop. This is the value used for Latency assertions and the degraded/failed response-time thresholds
Learn more in our documentation on Results.

​
Troubleshooting Common Issues

Symptom: destinationReached is false, yet the website or API responds normally.Root causes:
  • The configured port is firewalled — TCP SYN probes never receive a SYN-ACK or RST
  • The target host silently drops probe packets at the network edge
  • A middle-box rewrites or discards probe traffic before it reaches the destination
How to fix:
  1. Switch the probe protocol — try ICMP if the host responds to ping, or UDP for a connectionless probe
  2. For TCP probes, change the port to one that is explicitly open on the target (e.g. 80 or 22). For UDP/SCTP, keep a closed port — arrival is only confirmed by an ICMP Destination Unreachable reply
  3. Confirm reachability at the application layer with an API Monitor or TCP Monitor targeting the same host and port
Symptom: Several intermediate hops show no response, but the destination is eventually reached.Root cause: Routers commonly deprioritize or filter ICMP Time Exceeded replies for probe traffic without affecting real data forwarding. The hops are still routing your packets — they simply do not respond to traceroute probes.What to do:
  • Focus on destinationReached and final-hop latency rather than individual intermediate hops
  • If the trace is cut short before the destination, increase the Max Unknown Hops limit
Symptom: SCTP probes fail with a socket permission error on a self-hosted Checkly Agent.Root cause: Container runtimes drop CAP_NET_RAW by default. Traceroute monitors always need it — hop discovery listens for ICMP replies on a raw socket regardless of probe protocol — but SCTP is the case that surfaces an explicit socket error, because SCTP probes are also sent over a raw socket.How to fix — In Kubernetes, update your pod spec or Helm values:
In Docker:
CAP_NET_RAW only grants permission to open raw sockets. It does not escalate broader container privileges.