RESEARCH AND PRACTICE
Crypto WebSocket data quality: gaps, ordering and safe recovery
Build a practical checklist for crypto market-data feeds: sequence gaps, duplicate updates, stale snapshots and recovery before signals resume.
A connected WebSocket is not the same as a trustworthy market view. Messages can arrive late, a local consumer can fall behind, and a book can remain visible after the state needed to update it has been lost. The useful question is whether the current representation can be reconstructed from a valid starting point and the required updates. A quality check should answer that question before a model interprets the numbers.
Give every observation an identity
Retain the venue, product, channel, event identifier or documented sequence, event time and local receipt time. Sequence rules are channel-specific: a counter that is continuous for one stream may not be continuous for a filtered subset of another. Coinbase's exchange documentation explicitly discusses gaps and out-of-order delivery, which is why a consumer needs more than a connection-status icon. Keep parsing failures and unsupported message types visible in diagnostics. Silently converting malformed fields to zero can create a market event that never occurred and is harder to detect than an explicit missing value.
Rebuild from a consistent snapshot boundary
An order book normally needs a snapshot plus the updates that follow the snapshot's boundary, according to the chosen feed's protocol. Buffering, ordering and replay rules must be taken from that protocol rather than invented from another exchange's examples. Treat a fresh snapshot as a replacement state when the documentation says so. Mixing its levels with an older local book can preserve orders that have already disappeared. Record the recovery boundary and the earliest time at which derived indicators become valid again; reconnecting the socket alone does not establish continuity.
A hypothetical missing update
Imagine a channel whose documented sequence is continuous: a valid state at 100 is followed by updates 101 and 103. Update 102 may contain a cancellation at the best bid. Continuing directly with 103 could therefore overstate buying support even if every received price looks reasonable. Mark the dependent book features unavailable, start the documented resynchronisation process and resume only after the new state is coherent. Do not insert a fabricated empty update for 102. Equally, do not count a retransmitted 101 twice: duplicate handling must preserve the state that a single correct application would produce.
Measure freshness and backlog separately
Event age estimates how old the underlying market information is, while local processing delay reveals whether the consumer is falling behind. A heartbeat may show that a connection is alive without proving that every product's book or trade stream is fresh. Compare timestamps only after checking their units and clock assumptions; seconds mistaken for milliseconds can defeat an apparently strict age limit. Use a monotonic clock for local elapsed durations where possible. Keep per-product ages and queue depth rather than one global timestamp that can be refreshed by an unrelated active instrument.
Test recovery with faults you can explain
Replay a recorded segment after intentionally dropping an update, duplicating a trade, changing arrival order and interrupting the connection. The expected response should be specified for each channel. Verify that a gap produces a held indicator rather than a strong buy or sell reading, and that recovery does not replay the same trades into cumulative measures twice. Compare the rebuilt state with a fresh trusted snapshot where the protocol permits it. Tests should include quiet markets: the absence of trades can be legitimate, whereas a stale book must not become healthy simply because activity is low.
Expose uncertainty to the decision layer
Publish a compact quality state beside derived metrics: current, recovering, stale or unavailable, with an age and reason where useful. Preserve the last valid value for diagnosis only if it is clearly labelled; do not let that value enter a fresh ranking as though it had just been observed. Review the fraction of time each market is usable and whether outages cluster around volatile periods. A scanner that reports fewer candidates during missing data is behaving differently from one that examined the full universe and found no candidates. Honest coverage makes that distinction visible.
Sources and example scope
Sources support the definitions and mechanisms. Numerical scenarios are hypothetical teaching examples, not live prices, forecasts or reported HOSTuvo returns. Images are editorial illustrations.