FEED LIVE SESSION 00:00:00 UTC CHANNEL LEGAL SPORTS 12
TRANSPORT WSS / MQTT / SSE PUSH ~35 MS EU V1

Pinnacle odds latency: how we measure it

Last measured: 9 November 2026

Every page on this site says a price leaves our servers about 5 ms after it reaches us and that a client in Europe typically has it about 35 ms later. This page shows where those numbers come from, what they include, what they leave out, and how you can check them yourself.

Latest run (production, 9 November 2026, 01:10 UTC, 180 seconds, 7,131 price updates): median 1 ms from our receipt to our publish, and 2 ms from our receipt to a subscriber on the same machine. No update was lost: 7,229 frames entered our log and 7,229 left on the WebSocket.

1. The numbers

Legp50p90p95p99max
Our receipt → our publish1 ms5 ms6 ms11 ms19 ms
Our publish → subscriber (same machine)1 ms6 ms9 ms13 ms24 ms
Our receipt → subscriber (total, same machine)2 ms11 ms14 ms21 ms25 ms

Measured on the production server with the same /ws/feed endpoint customers use, subscribed to every sport. The run was at a quiet hour; at peak load the tail (p95 and above) is wider, which is why we publish the date and time of every run.

2. What we measure

Three moments, all read from one clock on one machine, so no clock offset can creep in:

  • Receipt: the moment our ingest receives the update from Pinnacle's push connection. It is stored with every update in our internal log.
  • Publish: the moment our WebSocket server sends the update. This is the ts field on every frame you receive.
  • Client: the moment a test subscriber reads the frame off its socket.

Updates are matched between the log and the socket by matchup id, update type and market version, taking the latest receipt for each key, because Pinnacle re-sends identical updates and the earliest receipt would overstate the delay.

3. What these numbers do not include

  • Pinnacle's own delay. Pinnacle's updates carry no publish timestamp, so nobody outside Pinnacle can measure the time from their price change to their push. Any "book to client" figure you see anywhere starts at the provider's receipt, as ours does.
  • The internet between us and you. This depends on where you are. From a client in Greece over TLS and Cloudflare we measured a median of 25 ms and a p95 of 84 ms for publish → client (16 September 2026), and a median of 33 ms in a later run (27 October 2026). That is the basis for "about 35 ms in Europe".
  • REST polling. REST returns the current state when you ask; its delay is your polling interval plus the request itself. These numbers are for the pushed WebSocket feed.

4. Check it yourself

  1. Synchronise your machine's clock with NTP. A clock that is a second off produces a latency that is a second wrong, sometimes negative.
  2. Connect to wss://pinnodds.com/ws/feed?key=YOUR_KEY and subscribe to a live sport (see the WebSocket docs).
  3. For each frame, subtract its ts (our publish time, epoch milliseconds) from your receipt time. That is our publish → your client, over your own network.

A free key is enough to read the REST feed; the WebSocket feed needs a plan that includes it, or a 3-day full demo on request.

5. How often we re-measure

We re-run this measurement after every change to the delivery path and at least once a month, and update the table and the date at the top of this page.