Skip to main content
Freshness checks turn market data from a raw response into a usable input. Run them before jobs that produce decisions, reports, alerts, exports, or models.
Check one market family directly when the job depends on a specific symbol:
For historical work, pair freshness with coverage over the requested window. Coverage from and to use Unix milliseconds.
1

Check service status

Stop early if the relevant venue family is degraded for your job.
2

Check symbol coverage

Confirm the data family exists for the requested time window.
3

Check incidents

Inspect whether a known interruption overlaps the window.
4

Attach the check to the job

Store the quality-check request ID next to the data request ID.

Data quality

Freshness, coverage, incidents, latency, and SLA routes.

Reliability and gaps

Build failure behavior for missing or delayed data.

​
Freshness Tolerance

Define tolerance before the job runs. A dashboard may tolerate a small delay, a backtest export may tolerate an annotated historical gap, and an alerting system may need to stop when order-book freshness is stale. The API can expose the state, but the application owns the policy decision.

​
Fields To Read

Symbol freshness responses expose the venue family, symbol, measurement time, and per-data-family freshness objects. For Hyperliquid core, read data.measured_at, then compare the relevant field such as data.orderbook.lag_ms, data.trades.lag_ms, data.funding.lag_ms, data.open_interest.lag_ms, or data.liquidations.lag_ms against the job threshold. The matching last_updated timestamp tells reviewers what market-data point the lag came from.

​
What To Log

Log the freshness route, measured timestamp, relevant venue family, symbol, data family, lag, last-updated value, and request_id. Store that next to the downstream output so a chart, model, or report can explain why it used or rejected a window.

​
Pair With Coverage

Freshness answers how current a data family is. Coverage answers whether the data family exists for the requested market and window. Use both when the job depends on historical correctness. Coverage should run before large historical jobs, model features, export orders, and backtests. Incidents should run when a known interruption could overlap the requested market or time range. Latency and SLA routes are useful for dashboards and service review, but they should not replace symbol-level freshness when the downstream job depends on one market.

​
Review Rule

A freshness check is useful only if the application has a threshold. Write down the maximum acceptable lag per job, then compare the API response to that threshold. Without a threshold, the check becomes a log line instead of a decision.

​
Next Step

Pair freshness checks with Data quality and Reliability and gaps before a job produces durable output.
Last modified on June 28, 2026