The Second You Measured vs the Hour Users Lived Through
The key difference from local networking: local faults tend to be persistent — broken stays broken — while cross-border problems are **almost always time-of-day**. International gateways congest at peak, routes shift at particular hours, carrier interconnects load up at night. All of these make one link behave completely differently depending on when you look.
So when a user reports stuttering at 8pm and you test at 10am the next morning, "everything looks fine" is the expected result. It doesn't mean the problem isn't real; it means you weren't measuring while it was happening.
| Approach | Reveals | Cannot see |
|---|---|---|
| Manual test when users report | Conditions at that second | Actual data from when it broke |
| Ping from your own facility | Quality of your line to theirs | Quality of the user's own line |
| One-off three-network test | Current differences between carriers | How each varies across the day |
| Scheduled continuous checks | Time-of-day trends and bad windows | (the only approach matching user experience) |
The table compares four common approaches. The third column is the point — what each one cannot see.
Three Problems Only Continuous Monitoring Catches
A single test is statistically unlikely to land on any of these:
- Evening peak congestion International gateway capacity is shared, and as evening usage climbs, latency and loss degrade together. That degradation usually concentrates into a few hours — while most testing happens during office hours, missing it entirely. Proving it exists requires continuous data spanning those hours.
- Intermittent routing changes Cross-border routes aren't fixed; carriers adjust them for cost and load. A single change can move latency from 80ms to 200ms with no notification at all. Without a long-run baseline you won't even know it got worse — because you don't remember what it used to be.
- Asymmetric degradation between carriers The three carriers run separate international gateways, so degradation doesn't arrive in step. Mobile might be badly affected in one window while Telecom and Unicom are fine. Even a test covering all three is still one slice of time — it can't reveal which carrier has a recurring problem in which hours.
What to Monitor
The metric priority is the same as for single readings: **loss first, latency second, bandwidth last**. But continuous monitoring adds a more important dimension — **variation**. A link steady at 120ms is usually more usable than one swinging between 60ms and 250ms, even though the latter has the better average.
So look at distribution, not just absolute values. For any metric, what matters is behaviour during peak hours rather than the mean — an average dilutes the three bad hours until the report looks healthy, while those diluted hours are exactly what users experienced.
One thing easily overlooked: **checks must originate from the user's network**. Testing from your own facility measures your line. If your users are on China Mobile, the test has to run on Mobile's network, or the data has nothing to do with their experience. This is why cross-border monitoring generally requires probes inside the target market.
Same Logic as Certificate Monitoring
If you read our piece on certificate expiry monitoring, the argument is structurally identical: **a one-off check cannot prove a continuous state**. There it was "renewal succeeded doesn't mean the certificate is being served"; here it's "fine this second doesn't mean users are fine".
The remedy is the same too — replace one-off checks with scheduled continuous ones, run from outside and from where users actually are. The only difference is that certificate monitoring cares about correctness of state, while network monitoring cares about the distribution of quality.
Three Layers of Implementation
From the basics up, build this in stages:
1. Establish a baseline first
Start recording normal latency and loss before anything is wrong. Without a baseline, no later number can be judged good or bad. The value of this step only becomes visible after the fact — by which point it's too late to create retroactively.
2. Cover all three carriers and the full day
Checks need to cover Telecom, Unicom and Mobile separately, across a complete day-night cycle. Testing only during office hours systematically misses the hours you most need to see.
3. Feed it into your existing monitoring
Connectivity data living on its own separate dashboard is data nobody checks regularly. Better to pull it via API into whatever monitoring or alerting the team already uses, alongside other metrics — that's what gets anomalies noticed rather than reported to you by users.
Three Things to Settle Before Monitoring
Work these out before configuring anything:
- Decide which target nodes to monitor Origin, CDN nodes, or both? Monitoring only the CDN hides origin problems when fetches slow down; monitoring only the origin doesn't reflect the path users take.
- Confirm probes sit on the user's side Cross-border monitoring requires checks originating in the target market, split across the three carriers. Testing inward from outside measures the reverse direction, and the two aren't necessarily symmetric.
- Decide how the data gets used Reviewing trends by hand, or threshold-based automatic alerting? The latter needs an API to feed existing systems. This determines whether you need a web tool or a programmable interface.
In Summary
Users reporting "slow in the evening" and your tests looking clean can both be true. Cross-border quality is a distribution that moves over time, not a fixed number, and one test samples a single point of it — usually the least important point, during office hours.
To check current three-carrier connectivity, the free tier of our speed test platform covers it. If you need scheduled checks, long-run trends, or the data fed into your own monitoring and alerting, the commercial API provides programmable access.