Why a Connected Exchange Feed Can Record 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. That is normal and documented; reconstructing the book from deltas is the consumer's job.

If a consumer treats each delta as if it were a complete book image, a downstream validation step that requires both sides of the book will reject almost every message. The rejection is silent: nothing throws, the connection stays open, throughput from the venue looks normal, and the only artefacts that survive are the full snapshots the venue sends on subscribe, one per pair per reconnect.

The result is a feed that is healthy by every connection-level measure and nearly empty by every data-level one.

During a routine minute-level coverage audit of Vultax's crypto order-book collection, one venue feed showed exactly this shape 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 surviving snapshots arrived in whole-pair batches roughly seventeen times per 48 hours, which is the signature of reconnects: each produced one usable image per pair, and the feed then went quiet again while every liveness check stayed green.

Measured against the live venue, message acceptance was 0.10%, 3 of 2,897 messages becoming a storable snapshot. After the connector was moved to full local book reconstruction, the same measurement returned 100%, 1,487 of 1,487, and the venue recorded 1,893 snapshots across 14 pairs in the following five minutes, placing it third among all connected venues by write rate. The change went live at 2026-09-02 01:03 UTC, the same day the audit ran.

Connection state, message throughput and process health all sit upstream of the loss. The drop happens between ingestion and storage, in a conversion step whose failure path is a return value rather than an exception.

This class of failure is not specific to any one pipeline. Independent accounts of real-time crypto data describe the same shape: connections that stay open but stop delivering useful updates, missing depth for particular venues, and reconstructed books that do not cover full days. Liveness and completeness are different properties, and monitoring the first says little about the second.

The check that catches it needs no knowledge of the failure mode: per-venue write rate compared against peer venues. A venue writing three orders of magnitude fewer rows than its peers is anomalous whatever any health endpoint reports.

Coverage is measured at minute level per venue, as the number of one-minute buckets holding at least one snapshot out of 1,440 per day, and gaps are preserved as gaps rather than interpolated. The 16-venue feed latency study reports those figures directly, and states the window each number comes from so it can be checked.

Any figure recomputed after 2026-09-02 01:03 UTC includes the venue described above at full coverage.

If you consume exchange market data, from venue WebSockets directly or through a vendor, the checks below rule this failure mode out explicitly. They are ordered by how much they catch relative to how hard they are to add.

• Alert on per-venue write rate against peer venues, not on connection state — relative anomalies need no knowledge of the failure mode
• Never let a conversion or validation step fail silently — a dropped message is an event worth counting even when it is expected
• Track sequence numbers where the venue provides them, and count detected gaps as a first-class metric
• Measure minute-level coverage, not uptime — the useful question is 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 periodically — that is how the acceptance figures above were obtained

The strip at the top of this page is not a screenshot of the day this was written. Every ten minutes Vultax re-reads the status pages of Coinbase, Kraken, Binance and OKX and Kalshi's exchange status, the trade tapes of five venues, and the five order books 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.

The first figure is how many of five venues report a healthy status right now; a 'minor' incident counts as unhealthy here because that is exactly the state in which a connected feed can go quiet. The second and third come from the tapes: the count and the largest of prints over $100,000 in the last thirty minutes. A venue whose status is green but whose tape shows nothing for half an hour is the failure mode this article describes.

The two Coinbase outages of the last year are the clearest public illustrations. In the AWS outage of 20 October 2025 Coinbase was unreachable while Binance, Kraken and OKX stayed online, and its support account's message was 'all funds are safe', which was true and beside the point for anyone whose feed had silently stopped. Coinbase's own postmortem of 7 May 2026 describes roughly eight hours down after an AWS thermal event and about twelve more to full recovery. A pipeline that only checks whether its socket is open would have recorded both as connected.

Status pages are a lagging source. They are written by people during an incident, they distinguish 'degraded' from 'down' in ways that do not map to whether messages are arriving, and they say nothing about the venue's competitors. That is why the strip on this page pairs the status count with the tapes rather than trusting either alone.