# Crypto Exchange Feed Latency and Coverage: 16 Venues Measured
Order-book feed latency on 16 crypto exchanges: medians from 35.0 ms (Coinbase) to 111.5 ms (BTSE), a 95th percentile of 288–590 ms on every venue, and data in every minute of the day. Plus the coverage check that catches a feed that stays connected and stores almost nothing.
Canonical URL: https://vultax.com/research/crypto-exchange-feed-latency-september-2026
Author: [Vultax Research](https://vultax.com/editorial-policy)
Published: 2026-09-02
Last public revision: 2026-09-16
Published research snapshots and calculations; these exports do not contain current quotes or live account data. Observation windows and populations are stated in the source captions and methodology. Missing metadata is unknown, not zero. Measurements describe observed data-feed behaviour from Vultax collection infrastructure over the stated windows. They are not a statement about any exchange's internal systems or conduct, and nothing here is financial advice.
## Key figures
- Feed latency at the 95th percentile: 288–590 ms — Range across 16 venues; every venue was above 100 ms at p95, while 15 of 16 were under 100 ms at the median
- Fastest median: 35.0 ms — Coinbase, over 64,647 snapshots in the one-hour latency sample
- Slowest median: 111.5 ms — BTSE, over 27,418 snapshots; the only venue with a median above 100 ms
- Coverage check, one venue feed: 12 of 1,440 min — Minutes with data over 24 hours while every connection-level check reported healthy; caught by the minute-level audit and fixed the same day
## The short answer
Vultax measured the order-book feeds of 16 centralised crypto exchanges and asked two separate questions. The first is how late data arrives. Fifteen venues had a median under 100 ms, from 35.0 ms on Coinbase to 111.5 ms on BTSE, but every venue exceeded 100 ms at the 95th percentile, which ran from 288.5 ms to 589.7 ms. The tail is what a cross-venue comparison waits for.
The second is whether data arrives at all. Over the 24 hours ending 2026-09-02 00:00 UTC all sixteen venues delivered data in every one of 1,440 minutes. The same minute-level check catches a feed that stays connected and stores almost nothing: it flagged one feed with data in 12 of 1,440 minutes while its connection reported healthy, and the fix was live the same day.
## What was measured
Vultax keeps order-book snapshot connections to a set of centralised crypto exchanges, and each snapshot carries a latency measurement taken at capture time, reported here without modelling or interpolation. The latency figures cover a one-hour sample of order-book snapshots; the coverage figures cover the 24 hours ending 2026-09-02 00:00 UTC. Both windows are short, and are stated so the result can be weighed against the sample.
- Latency — per-snapshot age recorded at capture, reported as the median (p50) and the 95th percentile (p95)
- Coverage — distinct one-minute buckets containing at least one snapshot, out of 1,440 per day, per venue
- No gap filling — missing intervals are reported as missing, never carried forward or interpolated
## Observed latency by venue
Medians cluster tightly. Fourteen of the sixteen venues sit between 69 ms and 93 ms, with Coinbase the outlier on the fast side and BTSE on the slow side.
### Observed latency by venue
Order-book snapshot age at capture, one-hour sample, September 2026. Ordered by median; rank 1 is the shortest tail. Coinbase over 64,647 snapshots, BTSE over 27,418.
| Venue | Median (p50) | 95th percentile (p95) | Rank by p95 |
| --- | --- | --- | --- |
| Coinbase | 35.0 ms | 288.5 ms | 1 |
| Bitrue | 69.5 ms | 311.6 ms | 2 |
| Bybit | 72.8 ms | 331.1 ms | 8 |
| WhiteBIT | 72.8 ms | 330.9 ms | 7 |
| Gemini | 75.4 ms | 361.8 ms | 13 |
| Binance | 76.8 ms | 328.1 ms | 5 |
| Gate.io | 77.2 ms | 333.5 ms | 10 |
| BitMEX | 78.0 ms | 338.9 ms | 12 |
| Poloniex | 79.8 ms | 338.6 ms | 11 |
| OKX | 80.0 ms | 326.5 ms | 4 |
| HTX | 80.4 ms | 324.3 ms | 3 |
| Bitget | 81.0 ms | 330.7 ms | 6 |
| KuCoin | 81.0 ms | 332.5 ms | 9 |
| Bitstamp | 82.9 ms | 406.0 ms | 15 |
| Upbit | 92.8 ms | 589.7 ms | 16 |
| BTSE | 111.5 ms | 383.5 ms | 14 |
[CSV](https://vultax.com/research/crypto-exchange-feed-latency-september-2026/data.csv?dataset=section-observed-median-latency-by-venue-table) · [JSON](https://vultax.com/research/crypto-exchange-feed-latency-september-2026/data.json?dataset=section-observed-median-latency-by-venue-table)
## The tail is where the venues differ
The 95th percentile behaves very differently. It ranged from 288.5 ms to 589.7 ms, and its ordering does not match the median's: Gemini, fifth-fastest by median, drops to thirteenth, while BTSE, slowest by median, is not the slowest tail. A latency quoted as a single number is almost always a median, and the median is the flattering half of the distribution.
## Why sub-100ms is a target and not a guarantee
Vultax describes its latency as a sub-100ms target, and this measurement is consistent with that wording: fifteen of sixteen venues sit under 100 ms at the median, but every venue exceeds 100 ms at p95 and the slowest tails run past half a second. For anyone comparing prices across two venues the tail is the operative number, because a gap on screen can pair a fresh quote on one venue with a stale one on the other. That is one reason [a price gap between exchanges is harder to capture than it looks](https://vultax.com/research/why-bitcoin-price-differs-between-exchanges).
Feed latency is also only one part of end-to-end latency: it measures a snapshot's age at capture, not the time for a signal to reach a screen, and vendors often quote the two interchangeably.
## Coverage: whether the data arrives at all
Latency is how late data arrives; coverage is whether it arrives at all. Across the 24-hour window, all sixteen venues returned data in every one of the 1,440 one-minute buckets, so continuity was not what separated them. Latency was.
An open connection is not the same as a feed that is recording, which is why Vultax audits coverage minute by minute rather than trusting connection health. Kraken is absent from the latency table, and the reason shows what that audit is for.
## When a connected feed records nothing
Most exchange WebSocket feeds deliver order-book updates as incremental deltas: a message may carry only bid changes or only ask changes, because only one side moved. Reconstructing the book is the consumer's job. A consumer that treats each delta as a complete book image will see almost every message rejected by any validation step that requires both sides. The rejection is silent: nothing throws, the connection stays open, throughput looks normal, and the only survivors are the full snapshots the venue sends on subscribe, one per pair per reconnect.
Vultax's minute-level coverage audit found that shape on its Kraken connection over the 24 hours ending 2026-09-02 00:00 UTC: 154 stored snapshots covering 12 of 1,440 minutes, against 29,720 to 1,326,344 snapshots with full-minute coverage for every peer venue. The survivors arrived in whole-pair batches roughly seventeen times per 48 hours, the signature of reconnects, while every liveness check stayed green.
Measured against the live venue, 3 of 2,897 messages (0.10%) became a storable snapshot. With the connector moved to full local book reconstruction, the same measurement returned 1,487 of 1,487 (100%), and the venue recorded 1,893 snapshots across 14 pairs in the next five minutes, third among all connected venues by write rate. The change went live at 2026-09-02 01:03 UTC, the day the audit ran; figures recomputed after that include Kraken at full coverage, and it joins the next latency measurement window.
## Why connection monitoring does not catch it
Connection state, message throughput and process health all sit upstream of the loss, which happens between ingestion and storage in a step whose failure path is a return value rather than an exception. The shape is not specific to one pipeline: [independent accounts of real-time crypto data](https://www.coinapi.io/blog/why-real-time-crypto-data-is-harder-than-it-looks) describe connections that stay open but stop delivering useful updates. Liveness and completeness are different properties.
The check that catches it needs no knowledge of the failure mode: per-venue write rate compared against peer venues. A venue writing far fewer rows than its peers is anomalous whatever any health endpoint reports.
## What to check in your own pipeline
If you consume exchange market data, directly or through a vendor, these checks rule this failure out, ordered by how much they catch for the effort.
- Alert on per-venue write rate against peer venues, not on connection state
- Never let a conversion or validation step fail silently; count dropped messages even when they are expected
- Track sequence numbers where the venue provides them, and count detected gaps
- Measure minute-level coverage, not uptime: what fraction of minutes hold data, not whether a socket was open
- Distinguish a broken feed from a quiet market; both produce gaps, and only one is yours to fix
- Reconcile stored data against a live sample of the venue, which is how the acceptance figures above were obtained
## How to read the live figures
The strip at the top of this page is not a screenshot of the day this was written. Every ten minutes Vultax re-reads five venues' status pages, the trade tapes of five books, the five order books, and CoinGecko's exchange tickers and rewrites the figures; the Vi IQ beneath them scores the same six domains the terminal scores for a pair, computed for BTC on the major spot venues, with any domain that cannot be computed shown as unavailable rather than filled in. Read the numbers as a live check on the argument above, and the revision notes at the end for what has changed since publication.
Latency is measured on Vultax's own collectors, so the strip shows the conditions they are measuring rather than a second latency figure: how many venues report healthy (a 'minor' incident counts as unhealthy, because that is the state in which a connected feed can go quiet), the cross-venue gap between mids, the mean best-quote spread, and large prints in the last half hour. A venue that is healthy on its status page and silent on its tape is the case the coverage check exists to catch.
## Context from elsewhere
Two public outages of the past year show what the tail looks like in practice. In the 20 October 2025 AWS outage Coinbase was unreachable while Binance, Kraken and OKX stayed up; Coinbase's postmortem of 7 May 2026 describes roughly eight hours down and about twelve more to full recovery after an AWS thermal event. Neither shows in a median; both show in the 95th percentile and in coverage. Status pages lag: they are written by people mid-incident, and their 'degraded' and 'down' do not say whether messages are arriving.
Latency claims elsewhere have become a marketing line. Prediction-market whale trackers advertise alerts 'in under two seconds' and typical figures of five to fifteen seconds, and none states its measurement method. A p50 and a p95 over a stated window across sixteen venues can be checked.
## Method and limits
This is a short-window observation from a single collection point, not a long-run reliability study. Latency measured from one vantage reflects the network path between that point and each venue as much as it reflects the venue, so the ordering could change from other infrastructure. Independent monitors that probe exchanges from many regions, such as [Glassnode's latency monitor](https://latency.glassnode.com/cex), report WebSocket round-trip time — a different quantity from the snapshot age reported here, and not directly comparable to it.
To watch the venues themselves, the BTC venue desk in the Vultax terminal shows each connected exchange's book side by side, with the cross-exchange gap, liquidity and large trades.
- Windows — one hour for latency, 24 hours for coverage, ending 2026-09-02 00:00 UTC
- Retention — raw order-book data is kept for five days, which bounds how far back these figures can be recomputed
- Scope — nothing here is a statement about any exchange's internal matching performance, and no claim is made about wrongdoing or the conduct of any venue or account holder
## Questions
### What is a good order-book feed latency?
Under 100 ms at the median for a well-connected collector on the major venues, which is where fifteen of sixteen venues sat in this sample. The tail matters more: the 95th percentile ran from roughly 290 to 590 ms across venues.
### Which crypto exchange has the fastest feed?
In this sample Coinbase had both the fastest median, 35.0 ms, and the shortest tail, 288.5 ms at the 95th percentile. Fourteen of the other fifteen venues had medians between 69 ms and 93 ms; the table lists every venue.
### How does Vultax measure feed latency and coverage?
Latency is the age of each order-book snapshot when the collector captures it, reported as a median and 95th percentile over a one-hour sample. Coverage is counted separately, as one-minute buckets holding at least one snapshot out of 1,440 a day, with gaps kept as gaps.
### Why can a connected exchange feed record nothing?
Because a feed can fail behind an open connection: the venue's publisher can stall, or the consumer can reject messages without an error, as when one-sided order-book deltas are treated as full snapshots. The socket reports healthy either way; comparing each venue's write rate and minute coverage with its peers catches it.
### Do exchange status pages catch a silent feed?
Not reliably. They lag, they describe the venue's own view of the incident, and they use categories such as 'minor' that do not say whether data is flowing. The live strip pairs the status count with what the tapes actually show.
## Revision notes
- 2026-09-07: Live figures and a Vi IQ for this subject now refresh every ten minutes on this page from outside sources and Vultax's own tables; a context section, the questions below and these revision notes were added.
- 2026-09-07: Added the two Coinbase outages as tail examples and noted the unmeasured latency claims of prediction-market alert tools for comparison.
- 2026-09-16: Now also covers feed coverage: how Vultax checks that every venue delivers data in every minute, and the check that catches a feed that stays connected but stores almost nothing. Venue latencies now sit in one table.
## Sources and methodology
- [Vultax order-book snapshot collection](https://vultax.com/methodology) — Per-snapshot latency recorded at capture time, minute-level coverage per venue, and the explicit-gap standard
- [Glassnode — Centralized exchange latency monitor](https://latency.glassnode.com/cex) — Independent WebSocket and FIX round-trip probes to major venues from multiple regions; measures a different quantity from snapshot age
- [Vultax editorial policy](https://vultax.com/editorial-policy) — Sourcing standards and AI disclosure
- [Yahoo Finance — AWS outage takes down Coinbase (20 Oct 2025)](https://finance.yahoo.com/news/aws-outage-takes-down-coinbase-104129926.html) — Coinbase unreachable during an AWS outage while Binance, Kraken and OKX stayed online; 'all funds are safe'.
- [Coinbase — A postmortem of our May 7, 2026 outage](https://www.coinbase.com/blog/a-postmortem-of-our-may-7-2026-outage) — The venue's own account of the May 2026 outage traced to an AWS thermal event; roughly eight hours down and about twelve more to full recovery, by the postmortem's timeline.
- [CoinAPI — Why Real-Time Crypto Data Is Harder Than It Looks](https://www.coinapi.io/blog/why-real-time-crypto-data-is-harder-than-it-looks) — Independent account of connections that stay open but stop delivering updates, silent data gaps and out-of-order updates
Changing market context is available on the [article page](https://vultax.com/research/crypto-exchange-feed-latency-september-2026). It is separate from the published study exported here.