Explore latency from different locations
Compare network measurements from our probes to public trading and blockchain endpoints. Choose a category, target and measurement method to see recent results and how they change over time.
These results start at the selected probe, not in your browser. To measure from your own connection, open Cloud Ping.
Categories
Loading measurements…
Where these targets are
A pin is drawn only where a position is known. Select a row for its details; the table below carries everything the map shows.
Results
Compare rows with the same method and time range. Lower latency describes this measured path; it does not guarantee faster trade execution.
Loading measurements…
Try a wider time range, a different probe, or clear the filters.
| Venue | Method |
|---|
Selected target history
| Bucket start | Probe | Method | Median (p50) | p95 | Samples | Failures |
|---|
Probes
Heartbeat and data age are shown separately: an agent can be running while its measurements are old, and that is not coverage.
Loading measurements…
| Probe | Location | Methods | Heartbeat | Public data age |
|---|
How these numbers are produced
- Where do the numbers come from?
- Every value on this page was measured by one of our registered probes. Cloud Ping runs in your browser and a backend test starts at our server; those are different starting points and can differ even for the same destination.
- What does a latency value measure?
- The method column names the operation that was timed. A TCP connection, a TLS handshake and an application response measure different work, so only compare rows with the same method.
- Does this measure order execution or blockchain finality?
- No. A network measurement says nothing about order matching, fills or finality. If we ever publish an application-level metric it will state the operation it timed and its assumptions.
- Why can a fast endpoint still show failures?
- Latency statistics use successful attempts only, and failed attempts are counted separately. A low median can sit beside a high failure count, so read both together with the sample count.
- Why might a location and a latency disagree?
- A CDN or shared address can answer near the probe while the service itself runs elsewhere. Declared positions and estimated positions are labelled separately, and a target with no known position is left off the map rather than placed by guess.
- How fresh are these results?
- Each row shows when it was last measured and is labelled stale once it is older than the freshness window. A missing value means there is not enough data for that selection, not that the target is fast.
- Why are some categories listed with no data?
- A category can be planned, catalogued but not yet measurable, or measured. A catalogued target is one we have recorded but not yet reviewed and enabled, so no traffic has been sent to it. We would rather show that state than an empty table that looks broken.
- Is there an API?
- Yes, the same read-only endpoints this page uses, under /api/latency/v1. They are anonymous, bounded and cover published targets only.