Avtim Latency Monitor

How we measure

1. 1
   Open a fresh connection.TCP handshake plus TLS handshake to the venue's public API host. That is the connect number: what every reconnect costs you.
2. 2
   Send a throw-away request.The first request on a new connection pays for session set-up on some venues. We do not count it.
3. 3
   Send three more and take the median.The lightest public call the venue has, usually server time. That is the request number: a warm round trip, the way a running connector sees it.
4. 4
   Repeat every sixty seconds, from the same machine.Samples are stored for ninety days and rolled into 24-hour averages and uptime percentages.

What the numbers mean, and what they do not

The probe runs from our server in Tokyo · AWS ap-northeast-1. It shows how responsive each venue's public gateway is from a European data centre, when it degrades, and when it stops answering. It does not show your execution latency: that depends on where your servers are, on authenticated endpoints, and on the venue's internal path from gateway to matching engine. Treat it as a weather report for venues, not as a benchmark of your own stack.

Public endpoints only, one lightweight request a second across all venues, a user agent that identifies the probe and links to this page. If you operate an exchange and would like us to adjust the schedule, write to us.