Coverage
What we actually captured.
Every vendor's data has gaps. Most don't tell you where. Below is our measured record for each underlying - per-day capture, cadence percentiles, and every interruption longer than five minutes with its UTC timestamps.
It's generated from the database rather than written, so it goes stale in hours rather than quarters. If you're evaluating us against another source, ask them for the same page.
BTC
ETH
SOL
XRP
TRX
AVAX
HYPE
BTC · day by day
2026-04-21
one bar per day · height = coverage · tick = gap over 5 min
2026-10-17
- coverage
- 99.729%
- cadence p95
- 84s
- cadence p99
- 233s
- lost
- 11.6h of 4320h
Gaps over five minutes · BTC
Every interruption, investigated, with what we observed. Where the logs no longer reach the answer is an honest "not established" rather than a likely story. The full record, including failures that cost no data, is on the operations page.
| From (UTC) | To | Duration | Cause |
|---|---|---|---|
| 2026-10-15 17:51 | 18:01 | 10 min | not recorded Not yet investigated. |
| 2026-10-13 09:00 | 09:41 | 41 min | exchange Deribit returned HTTP 503 Service Unavailable to everything we asked of it — REST calls and websocket handshakes alike — for forty-one minutes. Capture resumed 57 seconds after the last refusal. The start time, 09:00Z, matches a long row of earlier interruptions on this record, every one of them confirmed as an exchange outage. Our reconnection behaviour did not extend it, and this is the third incident where that can be shown rather than assumed: the websocket pool dropped 816 times and drew 816 distinct delays, which is the jitter added on 14 September doing its job. The sharper evidence is again an absence — not one 429 response in the window. A synchronised return would have produced them, as it did on 22 September. What was ours, and is not fixed by this entry: the L2 book daemon does not survive an outage it cannot reach through. It exhausted its reconnect budget and exited on 'server rejected WebSocket connection: HTTP 503', systemd restarted it, the new process met the same 503, and that cycle ran thirteen times across the window until the exchange came back. The chain collectors, which retry in place and never exited, were in exactly the same position and lost exactly the same data — so the restart loop neither helped nor hurt the outcome here. It is recorded because 2026-10-01 had the identical shape, which makes it twice, and because an exchange outage long enough to exhaust the budget is the normal case rather than the exceptional one. The forty-one minutes of order-book deltas inside the window are lost and unrecoverable; there is no historical book endpoint to refill them from. The chain snapshots are a true hole for the same reason the rest of this record's holes are. One further thing this incident exposed about our own instrumentation, now being fixed separately: every failed cycle logged a full traceback with locals, about 1,240 journal lines a minute against a baseline of 15, roughly 50,000 lines across the window. The traceback renders our own source, so a grep for '429' in the window returns 254 hits — all of them one comment line in our retry code, and none of them an exchange response. Instrumentation that buries the signal under its own source listing makes the next diagnosis slower, not faster. |
| 2026-10-08 01:34 | 01:44 | 10 min | our fault The third instance in eight days of the failure described in the 1 October entry, and the cleanest one: nothing else was wrong at the time, so the mechanism stands on its own. Deribit dropped nine connections at 01:34:15Z. One second later every one of them had reconnected and re-subscribed — 1,418 channels inside that second — and the first handshake rejection is stamped in the same second as the re-subscribe. Capture stopped for all seven currencies for the next nine minutes and resumed at 01:44Z, with no further drop in between. Unlike 1 and 6 October the pool was not flapping beforehand: three drops in volar-collector across the preceding twenty minutes, against 96 before the 1 October incident. One ordinary mass disconnection, answered by our entire pool at once, is sufficient on its own to cost ten minutes of capture across every currency we sell. The L2 book daemon is the control that isolates the cost to our own re-subscription. It held an established connection throughout, needed no new request, and was never refused: 3,577 writes in the window, zero disconnections, zero 429s, while every process that had to ask Deribit for something new was being turned away. The exchange was not unwell — it was refusing us, and specifically refusing the new requests we had just made far too many of. Our own steady-state rate was unchanged going in, which is the remaining open question rather than a defence: it shows nothing on our side spiked before the drop, not that our ordinary request rate sits comfortably inside the budget. The incidents of 10 and 11 September reached the same wall from the same baseline. |
| 2026-10-06 15:07 | 15:17 | 10 min | our fault The same failure as 1 October, five days later and from the same point in the code: Deribit dropped the websocket pool, the pool returned inside one second and re-subscribed 1,107 channels at once, and was then refused with 429 for nine minutes. The mechanism, and why none of the September fixes prevent it, is set out in the 1 October entry. What this incident adds is a warning about the gap list itself. The coverage report names four currencies — BTC, ETH, HYPE and XRP — and that understates what happened. All seven stopped after 15:07Z and none wrote again until 15:16Z. SOL and AVAX each landed a single snapshot at 15:12Z and TRX one at 15:11Z, which split their absence into two runs each shorter than the detector's threshold; they are therefore missing from the published scope while having lost almost exactly as much data as the four that are named. health_check's own freshness numbers four minutes in say it plainly — BTC 441s and ETH 441s against SOL 201s and AVAX 199s, which is one lucky write of difference. A single write inside a hole hides the hole. That is a defect in what we publish rather than in this incident, and it is recorded here because this is where it was found. The L2 book daemon again exhausted its reconnect budget and was restart-looped by systemd through the refusal, costing 912 seconds of BTC and ETH order-book deltas that cannot be recovered. |
| 2026-10-01 05:58 | 06:09 | 11 min | our fault Deribit closed our websocket pool without a close frame. That alone is routine and recoverable. What turned it into the gap published here is that the whole pool came back in the same second and re-subscribed every channel at once; Deribit then answered 429 Too Many Requests to everything that needed a new request — REST snapshot calls and websocket handshakes alike — and all seven currencies stopped. This is the fourth incident in the family that begins on 2026-07-14, and the first of three inside eight days (see 6 and 8 October). The mechanism is now measured rather than inferred. The backoff counter resets for any connection that held sixty seconds, so after a mass drop almost every connection reconnects at attempt 0 — and at attempt 0 the jittered delay is drawn from [0.5, 1.0] seconds. A pool dropped together therefore returns together: twenty-three connections reconnected within four seconds of the drop and re-subscribed 1,600 channels, and the first refusal arrived one second after the drop. The pool had also been flapping for the preceding twenty minutes, 157 disconnections across the two chain collectors, each drop manufacturing a fresh attempt-0 herd. None of the four fixes made in September reach this. Honouring Retry-After (13 August) governs how we retry a refusal, not how we return from a disconnection. Per-connection subscribe pacing (10 September) spreads two hundred channels inside one connection and cannot spread thirteen connections. Half jitter (14 September) randomises a fraction of the backoff ceiling, and at attempt 0 that ceiling is one second, so it disperses the herd across half a second. Reset-on-survival (1 September) decides when the counter returns to zero, and makes attempt 0 the common case rather than the rare one. The herd forms at the one point none of them act on, which is why the same ten-minute outage appears three more times on this record. The L2 book daemon failed louder in the same refusal: rejected on the handshake, it exhausted its reconnect budget, exited, and systemd restarted it into the same rejection — the shape repeated on 13 October. 617 seconds of BTC and ETH order-book deltas inside the window are lost and unrecoverable, because there is no historical book endpoint to refill them from. The chain snapshots are a true hole for the same reason as the rest of this record's holes. Nobody was told while it was happening. health_check detected it at 06:05:03Z and wrote 'Chain stale (threshold=120s)' for all seven currencies to its log, but alert email did not work until 13 October — so none of these three incidents reached a human at the time. |
| 2026-09-28 08:59 | 09:17 | 18 min | exchange Deribit refused every websocket connection for seventeen minutes, answering HTTP 503 to the handshake itself rather than dropping established sessions. Capture resumed thirteen seconds after the last refusal. Our own reconnection did not extend it, and this is the second incident where that can be shown rather than assumed. The pool reconnected 413 times across the window and drew 413 distinct delays — the jitter added on 14 September is what produces that. Under the previous behaviour every connection computed the same delay and returned together, which is what turned two exchange hiccups in September into ten-minute self-inflicted outages. The sharper evidence is the absence: zero 429 responses in the window. A synchronised return would have produced them, as it did on 22 September when an unattended database restart put every collector back in lockstep and 387 of them arrived at once. Here the exchange was refusing everything and there was nothing to capture regardless. |
| 2026-09-22 04:27 | 04:35 | 8 min | our fault An unattended package upgrade restarted the database underneath the collectors, and the synchronised recovery that followed hit the exchange's rate limit. apt-daily-upgrade.service runs from a systemd timer at 06:00 local every day. On this run it stopped and started postgresql@16-main. All five collector units lost their database connections and restarted within twelve seconds of each other, which left every Deribit websocket in the pool opened at the same moment. Sixteen minutes later those connections dropped together, reconnected together, and each one issued its post-reconnect instrument refresh at the same time. Deribit answered 429 Too Many Requests, and REST is what a snapshot needs for open interest and volume, so no snapshot could be assembled until the throttle cleared eight minutes later. The exchange was healthy throughout: zero 503 responses in the window. The 429s were a refusal of our own request burst, not an outage. Worth separating two things that look alike. The reconnect jitter added on 14 September worked here — three disconnections drew three distinct delays, so the websockets did not return in lockstep. What is not jittered is the REST call each connection makes after it reconnects: get_instruments and get_book_summary_by_currency fire immediately on recovery, and it was those, not the reconnections, that bunched. The fix for the websocket herd did not cover the REST herd behind it. The trigger recurs daily and is not specific to this date. |
| 2026-09-15 08:59 | 09:39 | 40 min | exchange Deribit returned HTTP 503 Service Unavailable continuously for forty minutes. Capture resumed within a minute of the last refusal. The start time, 08:59Z, matches eight earlier interruptions on this record, all confirmed as exchange outages. Our own reconnection behaviour did not extend it, and this is the first incident where that can be shown rather than assumed. The websocket dropped 719 times across the window and every one of those reconnections drew a different delay — 719 disconnections, 719 distinct values. The jitter added on 14 September after the 10 and 11 September interruptions is what produces that. Under the previous behaviour every connection computed an identical delay and they returned together, which is what turned two exchange hiccups into ten-minute self-inflicted outages. Here the exchange was refusing everything for forty minutes and there was nothing to capture regardless. |
| 2026-09-11 07:44 | 07:54 | 10 min | our fault The same failure as the day before, with the fix for it already deployed. Deribit throttled us with 429 for ten minutes and every currency stopped. 96 retries against /public/get_book_summary_by_currency and /public/get_instruments — our ordinary calls, refused, because the request budget had gone elsewhere. The fix shipped on 10 September paced each connection's re-subscription. It does nothing here, and the reason is worth recording. The ticker pool spreads instruments across about thirteen websocket connections holding two hundred channels each, so no single connection ever sends a large subscribe. When Deribit drops the connections it drops all of them together, they back off on identical schedules, and they reconnect in the same instant: eight of them waited exactly one second and then re-subscribed at once. Around two thousand six hundred subscriptions arrive simultaneously, and pacing within one connection cannot spread a burst that is spread across thirteen. This is a thundering herd, and the missing piece is jitter — the backoff delays are identical because nothing randomises them. That is the change being made now. The 10 September entry's account of the mechanism was wrong on this point and has been left as written rather than quietly corrected, because the sequence of two wrong readings is itself part of what happened. |
| 2026-09-10 14:08 | 14:18 | 10 min | our fault We exhausted our request budget at Deribit and were throttled with HTTP 429 for ten minutes. There were no 503 responses, so the exchange was serving other traffic and refusing only ours. It was not caused by polling too hard. Our routine REST rate is about seven requests a minute — one book summary per currency, plus an instrument list per currency every five minutes — and during the interruption almost every one of those ordinary calls was refused. The budget had been spent elsewhere: each time the websocket reconnects, the collector re-subscribes to a ticker channel for every live instrument, 2,440 of them. Nine reconnections completed inside those ten minutes, so roughly twenty-two thousand subscription operations landed in a limit that REST and websocket traffic share, and the ordinary calls had nothing left to spend. This is the fourth interruption of this family, after 2026-07-14, 2026-08-13 and 2026-09-01, and the first where the cause is the cost of reconnecting rather than the behaviour of a retry. The two earlier fixes both held: the REST path honoured Retry-After, and the reconnect backoff escalated 1s, 2s, 4s, 8s, 16s, 32s to a 60-second ceiling, so 65 attempts produced only nine completed reconnections where the same shape on 1 September produced two hundred. Without that the interruption would have been longer. What is not yet fixed is the price of a reconnection. Re-subscribing every instrument at once is affordable occasionally and not affordable nine times in ten minutes. |
| 2026-09-05 08:59 | 09:36 | 37 min | exchange Deribit returned HTTP 503 Service Unavailable continuously for the whole window. Capture resumed within a minute of the last refusal. The L2 book daemon separately exhausted its reconnect budget and was restarted by systemd 270 times during the same period; that is our defect and is being fixed, but it did not lengthen this interruption — the exchange was refusing every request throughout, so there was nothing to capture, and chain collection resumed as soon as the 503s stopped. |
| 2026-09-01 06:01 | 06:15 | 14 min | our fault Deribit closed every one of our websocket connections at the same second, without a close frame. That alone is routine and recoverable. What turned it into a ten-minute interruption is our reconnect loop: the backoff counter resets on a successful CONNECT rather than on a connection that survives, so a socket that establishes and immediately dies restarts the delay at one second indefinitely. It never escalated. Two hundred reconnect cycles followed, each re-subscribing every channel, and Deribit answered 820 times with 429 Too Many Requests. Capture resumed when the cycle settled. This is the third rate-limit incident of the same family after 2026-07-14 and 2026-08-13; the fix made in August taught the REST retry path to honour Retry-After and did not touch the websocket reconnect path, which is where this one happened. |
| 2026-08-25 09:00 | 09:15 | 15 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-08-18 09:00 | 10:27 | 87 min | exchange Deribit returned HTTP 503 Service Unavailable. The longest interruption on record. |
| 2026-08-16 14:01 | 14:07 | 6 min | not established Observed at the time, but the cause is not established. Capture degraded on all three bases then collected for about seven minutes. The journal no longer reaches back past 2026-09-04, and this window predates it by five weeks. |
| 2026-08-13 09:56 | 10:04 | 8 min | our fault We exceeded Deribit's request rate limit again and were throttled with HTTP 429. This is a recurrence of 2026-07-14, from the same line of code: the retry path waited 0.1s, 0.2s, 0.4s for every error including a throttle, and ignored the Retry-After header telling us how long to wait. Retrying a rate limit after 100ms is what keeps it tripped, so our own traffic sustained the outage a second time. The July incident named this defect and nothing was changed; publishing a cause is not the same as fixing it. The retry path now honours Retry-After, with a one-second floor and a sixty-second ceiling, for 429 only — a 503 means the exchange is down rather than annoyed, and still retries fast. |
| 2026-08-11 08:58 | 09:30 | 32 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-08-06 00:45 | 00:54 | 8 min | not established Observed at the time, but the cause is not established. All three bases then collected went stale together for about four minutes, inside a day that was already degraded end to end: 2026-08-06 ran at a 92.7 s median against a normal 80-84 s and produced 894 ETH snapshots instead of ~1055, as roughly ten seconds added to every interval. Whether the exchange was slow or we were, nothing surviving can say — the journal no longer reaches back past 2026-09-04. |
| 2026-07-21 08:59 | 09:22 | 23 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-07-17 08:59 | 09:10 | 12 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-07-14 02:53 | 03:02 | 10 min | our fault We exceeded Deribit's request rate limit and were throttled with HTTP 429. The collector's retry path had no backoff proportional to the throttling, so it kept requesting and kept being refused — our own traffic sustained the outage. Capture recovered and failed again between retries, so it is measured as two separate interruptions rather than one continuous outage. |
| 2026-07-14 02:41 | 02:50 | 9 min | our fault We exceeded Deribit's request rate limit and were throttled with HTTP 429. The collector's retry path had no backoff proportional to the throttling, so it kept requesting and kept being refused — our own traffic sustained the outage. Capture recovered and failed again between retries, so it is measured as two separate interruptions rather than one continuous outage. |
| 2026-07-07 08:59 | 10:27 | 88 min | exchange Deribit returned HTTP 503 Service Unavailable. Longest to date. |
| 2026-06-30 08:58 | 09:23 | 24 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-06-25 15:09 | 15:16 | 6 min | exchange Deribit rejected requests with HTTP 403 Forbidden. The rejection was at the edge rather than the API, and cleared without action from us. |
| 2026-06-12 07:30 | 07:41 | 11 min | exchange Deribit returned HTTP 503 Service Unavailable. |
| 2026-05-19 08:59 | 09:33 | 35 min | exchange Deribit returned HTTP 503 Service Unavailable to every request. |
| 2026-05-13 13:32 | 13:41 | 10 min | not established Not established. |
| 2026-05-12 21:30 | 21:50 | 19 min | not established Not established. |
| 2026-05-12 12:51 | 12:59 | 8 min | not established The cause is not established and cannot now be established. An eight-minute degraded window on all three bases then collected, newly visible on 2026-10-14 when the gap rule began counting consecutive degraded intervals rather than single ones. Nothing we still hold covers it: collector logs reach back to 2026-05-13T15:53Z, a day later, and the health-check log's first dated line is 2026-05-21T22:55Z. It resembles later confirmed incidents, and a matching signature is not evidence. |
| 2026-05-06 08:59 | 09:27 | 27 min | not established Not established. The start time matches six later interruptions that were confirmed as exchange outages, but a matching signature is not evidence and this one is not claimed as upstream. |
| 2026-04-27 11:43 | 12:24 | 41 min | not established Not established. |
How this is measured
Time coverage, not a snapshot target. We report the fraction of the elapsed window during which the collector was actually capturing, derived from measured gaps. There is deliberately no "expected snapshots per day" denominator: the capture cadence changed from ~82 s to 60 s on 2026-08-12, and any fixed denominator would misreport one era or the other.
A gap is over five minutes. Comfortably above any normal spacing, so ordinary cadence is never counted as an outage. Each one is investigated and its cause published on the operations record - the exchange returning 503, our own rate-limit breach, or, where the logs no longer reach, an honest "not established".
Live capture and archive are separate. The figures above cover our own continuous capture since 2026-04-21. The historical BTC archive is a different provenance and is described on each currency's page and in the methodology.
Daily OHLC bars
Daily open/high/low/close/volume bars for
each base's own Deribit PERPETUAL instrument (e.g.
BTC-PERPETUAL).
These are PERPETUAL instrument bars, not index bars, and not options data - Deribit does not publish an index OHLC series,
and this is a different instrument from every options chain, surface,
greek and trade-tape dataset on this page. Every bar carries
instrument_name, so the series is identifiable from the
payload alone, not only from this page.
Coverage start not yet published. The backfill that would measure this dataset's earliest available day has not run. We publish a start date only once it has been measured against what actually landed - not before.
DVOL bars and
settlement prices are served by
/v1/dvol/{underlying}/history and
/v1/settlement/{underlying}/history. Both are
live-forward only: they begin when our own reference
collection began and carry no history before that date.
Deribit publishes a DVOL series reaching back years - that series is not
this one, and we do not hold it.
Coverage start not yet published.
The word "history" in an endpoint name is not a coverage claim. As with
daily OHLC bars above, we publish a start date only once it has been
measured against what actually landed - so until then, treat the extent as
unknown and read it from the response's _meta.as_of rather
than from this page.
Trade tape, liquidations and blocks
Coverage start dates for BTC, empirically established by probing Deribit's own history API across calm days and every major crash - not rounded, not softened. These probes were run on BTC. Deribit did not list ETH options until March 2019, SOL options until March 2024, or XRP options until March 2024 (TRX and AVAX not until January 2026), so on those currencies no dataset starts earlier than its own tape does; each currency's coverage page carries its own dates.
| Dataset | Coverage start (BTC) |
|---|---|
| Options liquidations | November 2018 |
| Block trades | September 2019 (meaningful volume from January 2020) |
| Combo / multi-leg flags | November 2022 |
History is still landing. These datasets are being built now, currency by currency, as the historical backfill runs. Until a currency's backfill completes, any month for it may return 404 simply because the file has not been built yet - which is a different thing from the month being empty. The full history back to the dates above arrives as each currency's backfill lands.
Liquidations are event-driven, not a steady rate: most months legitimately
contain zero rows, and empty months are never written. Once a month is
built, a 404 on liquidations/{month} means exactly that - no
qualifying rows - not a gap. Both derived datasets are Pro tier, same as
the trade tape itself - no new SKU, no extra price.