No fault found
The fault is real, recurring and intermittent. It is also gone by the time anyone tests, which means every ticket closes the same way and the pattern never accumulates into anything anybody has to act on.
Intermittent faults are hard for providers in ways worth acknowledging. A support engineer receiving "it was slow yesterday afternoon" has nothing to test. Their monitoring is device-level and shows healthy interfaces. Closing it is not obstruction; it is the only available action.
What changes the outcome is arriving with the fault already characterised: when it starts, how long it lasts, which hop inside their network it begins at, and how many times it has happened this month.
What a defensible report contains
A specific hop, not a region
Per-hop measurement means the first degraded hop has an address. "Loss begins at this address in your network, and the hops before it are clean" is a testable claim rather than an accusation.
Hops ruled out as well as in
A hop that stops answering probes but still forwards traffic is marked as such rather than reported as loss. Handing a provider a report that blames a healthy router is how a report gets dismissed, along with the next one.
A recurrence pattern
Continuous measurement turns four separate tickets into one graph with four episodes on it, at the same time of day. That is a capacity conversation, and it is very hard to close as no fault found.
The route at the time
The path is fingerprinted every pass, so a degradation that coincides exactly with a reroute makes the cause obvious, and rules out the changes your own team made that morning.
The fault only exists in one direction
Traffic between two of your sites frequently does not take the same route in both directions. Each site measures outward, sees a clean path, and concludes the problem is at the other end. Both are looking at the healthy direction.
A mesh test measures between your own agents in every direction at once, so the two legs appear side by side. A degradation that exists only from Manchester to Leeds, and not the reverse, is visible immediately instead of being the last hypothesis anybody tries.
This is also the fastest way to end the internal version of the argument, where two teams each demonstrate that their end is fine.
Why it survives scrutiny
A provider's network engineer will push back on evidence produced by ordinary traceroute, and they are frequently right to. A spliced path assembled from several routes, or ICMP rate limiting reported as loss, are both real weaknesses in the usual method.
Measurements that hold the flow constant, and that separate a router declining to answer from a router dropping traffic, do not have those weaknesses. Theconfidence model exists partly so that a report is not dismissed on a technicality that would have been fair.
It rules you out too, and that is most of the value
The same record that locates a fault in a carrier's network will, more often than most people expect, locate it inside yours. A saturated uplink, a duplex mismatch, a firewall doing more inspection than it has capacity for.
That is not a disappointing outcome. Finding it in an afternoon rather than after three weeks of escalation is the same win, and it preserves the credibility that makes the next genuine provider escalation land.
Teams that measure this way tend to send fewer tickets and get faster responses to the ones they do send, because the provider learns that a report from them is usually correct.
Bring the recurring one
Everybody has a fault that has been closed as no fault found more than once. That is the one worth pointing this at first.
Build the evidence for the provider conversation.
An illustrative investigation. Follow the evidence from where it was measured to the result you need to explain.
1.Measure from the affected location
Place an agent where the problem is experienced. Compare the same target from another vantage point to see whether the issue is local or shared.
Set up a vantage point2.Separate the path from the application
Use Path Health for the route and HTTP for request timing. Compare DNS, connection, TLS and response phases before deciding which layer to investigate.
Choose your checks3.Inspect the moment that matters
Choose the time window, inspect individual results and read the trust qualifiers. Keep the target and vantage point alongside the evidence.
Read the results