Recipe 41 of 65
Is a day of Hyperliquid snapshots complete? Count the 5-minute snapshots and spot gaps
/v1/hyperliquid/archive/datasets gives each day's positions file a snapshots count and lists the hours that were rebuilt; the gaps inside a day come from the file's own snapshot_ts values.
GET /v1/hyperliquid/archive/datasets answers it in one call: each day there that has a positions file carries
snapshots, the number of distinct
snapshot times in that file, counted from the file itself. A normal day holds about 250 to 290, because snapshots run
5 to 7 minutes apart. A day can also list reconstructed_hours: hours rebuilt by replaying fills instead of being
read from the venue's state. To find where in a day a gap sits, download the file and look at the spacing of its
snapshot_ts values. The endpoint page is Archive file index.
Quick answer
Read the index and keep each positions day's count.
# snapshots, rows and rebuilt hours of every published positions day, newest first
curl -s -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/archive/datasets" \
| jq '[.dates[] | select(.streams.positions) | {date, snapshots: .streams.positions.snapshots, rows: .streams.positions.rows, reconstructed_hours: .streams.positions.reconstructed_hours}]'Example response
Captured from the live API on 2026-10-24 at 17:16 UTC, the output of that jq filter, trimmed to 3 of 169 days.
All three are full days, but on 2026-10-23 the 11:00 and 12:00 UTC hours were rebuilt from fills. Across the 169 published days the count ran from 71 (2026-05-08, the partial first day) to 291; ten days held fewer than 250, and 52 days list rebuilt hours.
[
{
"date": "2026-10-23",
"snapshots": 286,
"rows": 122700235,
"reconstructed_hours": [
"2026-10-23T11:00:00Z",
"2026-10-23T12:00:00Z"
]
},
{
"date": "2026-10-22",
"snapshots": 286,
"rows": 121450245,
"reconstructed_hours": null
},
{
"date": "2026-10-21",
"snapshots": 274,
"rows": 116812500,
"reconstructed_hours": null
}
]Variations
Only the thin days. Keep the days under 250 snapshots.
# the days whose positions file holds fewer than 250 snapshots
curl -s -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/archive/datasets" \
| jq -r '.dates[] | select(.streams.positions) | select(.streams.positions.snapshots < 250) | "\(.date) \(.streams.positions.snapshots)"'Where the gaps are inside a day. Download the day's positions file (about 1.9 GB) and list every spacing over 10 minutes.
# ask for the link and download the 2026-10-23 positions file in one step
curl -L -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/archive/url?dataset=positions&date=2026-10-23&redirect=1" \
-o positions-2026-10-23.parquetSELECT * FROM (
SELECT snapshot_ts, snapshot_ts - lag(snapshot_ts) OVER (ORDER BY snapshot_ts) AS gap
FROM (SELECT DISTINCT snapshot_ts FROM 'positions-2026-10-23.parquet')
)
WHERE gap > INTERVAL 10 MINUTE
ORDER BY snapshot_ts;Before you rely on it
A count is not a gap check
Snapshots are irregular, 5 to 7 minutes apart, so a day of 280 can still hide a 30-minute hole that faster cycles
made up elsewhere. The count tells a thin day from a normal one without opening the file; the spacing of
snapshot_ts in the file is the gap check. A file is never padded: a source outage that could not be rebuilt stays a
gap.
Rebuilt hours are estimates
In reconstructed_hours the positions were replayed from fills, not read from the venue's state: margin_used and
liquidation_price are 0 and state_ts is 1970-01-01 on those rows. Their sizes matched the next real snapshot at
97% or better, except the hours also listed under reconstructed_lower_match_hours, which matched at 83 to 97%.
Ask your agent
No MCP tool reads the Parquet archive or its index: run the Quick answer call and query the files locally.