Identify which segment of the network path is causing latency or packet loss by tracing the route from a Cloudmon probe to a target host and isolating performance issues at the ISP level.
ISP Path Monitor extends standard trace path analysis by identifying the ISP segment of the network route and surfacing ISP-level performance metrics. Where a standard traceroute shows each network hop with its latency, ISP Path Monitor specifically highlights the hops that belong to the ISP or carrier network and measures jitter, latency, and packet loss at that segment.
This is useful for diagnosing situations where a host is reachable but performance is degraded and the cause appears to be outside your network boundary. If the ISP segment is identified as the problem hop, the traceroute data can be used to escalate the issue to the carrier with specific evidence — showing which hop is introducing latency and the measured values at that point in the path.
Navigate to Synthetic → Network → ISP Path to view all configured ISP Path monitors.
Navigate to Synthetic → Network → ISP Path Monitor and click the Add button. Fill in the fields as follows:
| Field | Description |
| Probe | The Cloudmon probe that will initiate the traceroute. For ISP-level analysis, use a probe with internet access so the full path including the ISP segment is visible. |
| Name | A descriptive name for this monitor, such as "Branch Office ISP" or "Data Centre WAN Path". |
| Target | The hostname or IP address to trace the route to. |
| Protocol | The protocol used to send probe packets. Different protocols may produce different results depending on how intermediate routers handle them. |
| Number of Probes | The number of probe packets sent per hop at each polling interval. More probes produce more accurate latency and packet loss measurements but increase test traffic. Default is 1. |
| Path MTU Discovery | When enabled, Cloudmon detects the maximum transmission unit along the path. Useful for identifying where packet fragmentation may be occurring, which can affect application performance on high-throughput links. |
| Detect Asymmetric Path | When enabled, Cloudmon checks whether the return path differs from the forward path. Asymmetric routing can cause unexpected latency differences and complicate troubleshooting. |
| Traffic Class (DSCP) | The DSCP marking applied to probe packets. Use this to test how different traffic classes are routed and handled across the path. Default is Best Effort (DSCP 0). |
| Prefer IPv6 | When enabled, Cloudmon uses IPv6 addressing for the traceroute where available. |
| Interval | How frequently the traceroute is run. Default is 5 minutes. Because traceroutes are more resource-intensive than a simple ping, shorter intervals should only be used when frequent sampling is required. |
| Group | Assign this monitor to one or more Cloudmon groups for organised access and bulk alarm rule association. |
| Depends On | Link this monitor to a parent device. Alarms for this monitor are suppressed if the parent device is down, preventing noise from cascading failures. |
| Tags | Optional labels for grouping and filtering this monitor in dashboards and reports. |
| Alert Profile | Select an existing alert profile to apply to this monitor. Alert profiles define the thresholds and notification settings used when a condition is breached. |
Click Save. Cloudmon begins tracing the route at the configured interval immediately.
For each ISP Path Monitor monitor, Cloudmon traces the full network path from the probe to the target and records per-hop metrics at every polling interval. The results show:
Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Learn more.
To configure an alarm for an ISP Path Monitor monitor, navigate to Synthetic → Network → ISP Path Monitor → [Select Monitor] → Settings → Alarm Rule and click Add Trigger.
| Issue | What to check |
| Hops showing as * or timing out | Many routers in carrier networks are configured to drop or deprioritise ICMP TTL-exceeded responses. A hop showing * does not necessarily indicate a problem — check whether the hops after it respond normally. If the final destination responds, the path is functional. |
| ISP segment not identified | ISP identification relies on IP geolocation and ASN data. If the ISP segment is not identified, the hops may belong to a network not yet in the geolocation database, or the probe may not have internet access for the lookup to complete. |
| Path changes frequently | Frequent route changes can indicate load balancing across multiple paths at the ISP level, which is normal for large carrier networks. If the changes coincide with performance degradation, escalate to the ISP with the recorded hop data as evidence. |