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. The Add/Edit panel is organized into four sections: Monitor Details, Advanced Details, Configuration Details, and Alert Settings.
Monitor Details: basic identification details for this monitor.
| 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 | Choose ICMP, TCP, or UDP for sending probe packets. Different protocols may produce different results depending on how intermediate routers handle them. |
| Port* | The destination port to use for the traceroute when the Protocol is set to TCP or UDP. |
Advanced Details: advanced probe, path discovery, traffic, and TCP options.
| Field | Description |
| 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. |
| 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 "Default (Best Effort) - DSCP 0". |
| Prefer IPv6 | When enabled, Cloudmon uses IPv6 addressing for the traceroute where available. |
| Probe Type | The type of TCP probe packet sent, such as SYN. Different probe types may be needed depending on how firewalls along the path handle specific TCP flags. |
| Maximum Segment Size (MSS) | An optional maximum segment size in bytes to use for TCP probe packets, useful for diagnosing MTU and fragmentation-related issues at a specific segment size. |
Configuration Details: polling interval, groups, dependencies, and tags.
| Field | Description |
| Interval | How frequently the traceroute is run. 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 Settings: configure the alert profile for this monitor.
| Field | Description |
| 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. |
| User Groups | The user groups that should be notified when an alarm is raised for this monitor. |
| Third Party Services | Third-party integrations (such as Slack, Teams, or ITSM tools) to notify when an alarm is raised for this monitor. User Groups and Third Party Services set here at the monitor level are automatically inherited by the attached alert profile. |
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 apply an alert profile to a specific ISP Path monitor, open the monitor's Edit panel and select the desired profile from the Alert Profile field under Alert Settings. From the same section, you can also assign the User Groups and Third Party Services that should be notified. These are inherited automatically by the attached alert profile, so the notification routing only needs to be set once per monitor.
| 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. |
| Traceroute using TCP or UDP returns no usable path data | Verify the Port field under Monitor Details is set to a port that is open on the target and not blocked by an intermediate firewall. If using TCP, also check the Probe Type setting under Advanced Details, since firewalls may treat SYN probes differently from other TCP flag combinations. |