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.
Each monitor also includes an Insights tab, which runs a set of automated path checks after every poll and reports the result for each one. This makes it quicker to see whether a path problem exists and where on the path it is.
Navigate to Digital Experience → Synthetic → Network → ISP Path to view all configured ISP Path monitors.
Navigate to Digital Experience → 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. The Jitter and Multiple paths insight checks require 2 or more. |
| 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. The Path MTU insight check requires it to be enabled. |
| 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:
ISP Path Insights runs a set of automated checks against the traced path after every poll and reports the result for each one, such as non-responding hops, packet loss, latency spikes, and ISP boundaries. This shows whether a path problem exists and where on the path it is, without reading the hop table line by line.
Viewing Insights: navigate to Digital Experience → Synthetic → Network → ISP Path, click the name of a monitor to open it, and select the Insights tab. The tab sits alongside Overview, Log Report, Outages, and Alarms. Insights reflect the latest poll and are not affected by the time range. The per-poll history is in the Log Report tab.
| Section | What it shows |
| Insights Score | An overall score for the path, shown as a percentage gauge. |
| Checks | The total number of checks, with how many passed and how many were not evaluated. |
| Failed by severity | The number of failed checks, split by severity. When no check has failed, it shows 0 Failed checks. |
| Path Map | The traced path with one marker for each hop. The marker colour shows the hop state, OK or No Response, and hops flagged by a check use the severity colour: Critical, Warning, or Info. The bars show the round-trip time (RTT) at each hop, and the ASN and provider name are labelled under the hops where they apply. |
| Path Checks | The list of checks with a one-line result for each. Use the filters to show all checks, or only those with a given result such as Info, Passed, or Not evaluated. |
Path checks: each poll evaluates the following checks.
| Check | Description |
| Non-responding hops | Routers that do not answer probes. This is common and usually harmless. The detail shows the hop ranges that did not respond. |
| Return path | Reports whether the forward and return paths differ. |
| Destination reachability | Reports whether the destination was reached, and in how many hops. |
| Packet loss | Reports packet loss on the responding hops. |
| Destination port | TCP monitors only. Reports whether the destination port was open, closed, or filtered by a firewall. |
| Latency spike | Reports whether there is an abnormal latency jump between hops. |
| ISP boundary | Reports whether the path stays within a single provider or crosses more than one. |
| Path stability | Reports whether the ASN path is stable. |
| Private network segment | Reports whether private addresses appear beyond the network edge. |
| MPLS segment | Reports whether MPLS labels were seen on the path. |
| Path MTU | A path MTU below 1400 bytes means tunnels or VPN on the path and fragmentation. Requires Path MTU Discovery to be enabled. |
| Jitter | Requires a Number of Probes of 2 or more. |
| Multiple paths | Requires a Number of Probes of 2 or more. |
Each check shows one of the following results:
Check details: select a check in the list to open its detail window, which shows the Status, Severity (Critical, Warning, or Info), What it checks, and Finding. Where a finding relates to a single hop, the window also shows the Hop. Some detail windows include a table of the affected hops. Click View in Hop Table to jump to those hops, and click Close to return to the list.
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. |
| Insight checks show Not evaluated | Some checks only run when a requirement is met. Enable Path MTU Discovery under Advanced Details for the Path MTU check, and set the Number of Probes to 2 or more for the Jitter and Multiple paths checks. The Destination port check applies to TCP monitors only. |