Status monitoring

Status monitoring turns API health, ingestion state, freshness, incidents, latency, and SLA signals into a decision about whether downstream work should run. The public status page is a product surface. It checks service health, coverage, incidents, and market-family signals. The docs surface explains how those signals should be used by clients.

Status Signals

Signal	Use it for	Docs
REST liveness	Whether the API edge is responding	REST API
WebSocket liveness	Whether stream service checks are healthy	WebSocket
Coverage	Which venue families, symbols, and data families are available	Data availability
Incidents	Known interruptions or degraded windows	Data gaps
Freshness	Whether latest data is inside tolerance	Data quality
Request IDs	Support and debugging across failed probes	Responses, Errors

Client Policy

Separate service health from data trust

A healthy service can still return data that is stale for a specific job.

Check the relevant family

Inspect the venue family, symbol, and data family your workflow needs, not only global status.

Record the decision

Store status, coverage, incident, freshness, and request-ID context with downstream output.

Fail visibly

If status or freshness is outside tolerance, stop or mark the output instead of silently continuing.

Status Check Checklist

Record enough context to distinguish a global outage from a stale market, a coverage miss, or a client-side request problem.

Field	Capture
Check type	Public status page, `/v1/data-quality/status`, coverage, incident, freshness, latency, or SLA
Route and method	The exact API route or status surface the workflow checked
Venue and market	Hyperliquid core, Spot, HIP-3, HIP-4, Lighter, symbol, pair, or market slug
Data family	Trades, candles, L2, L3, L4, funding, open interest, liquidations, exports, or streams
Observed time	The UTC time the check ran and the latest timestamp returned by the data surface
Tolerance	The freshness or completeness threshold the downstream workflow requires
Request context	Status code, error code, `request_id`, cursor, and retry count when available
Decision	Continue, delay, narrow the request, mark the output, or escalate with support context

Use the global status view to decide whether a broad service issue is already known. Use symbol-level coverage and freshness checks to decide whether one workflow should run right now. Those are related signals, but they should not collapse into the same client decision.

Run Or Delay Rule

Status checks should end in one of a few explicit decisions.

Decision	Use when	Client behavior
Continue	Service health, coverage, and freshness are inside the workflow tolerance	Run the job and store the check result with the output
Narrow	One venue family, symbol, schema, or time window is outside tolerance	Reduce scope and record the excluded market or range
Delay	The needed data is stale, incident-affected, or still catching up	Stop the job and retry after the next scheduled check
Mark output	The workflow can tolerate partial context but the reader must see it	Attach the incident, freshness, or coverage state to the output
Escalate	The issue blocks a customer workflow or repeats across checks	Send route, symbol, timestamps, request ID, and status context to support

Use the same rule for REST pulls, WebSocket replay, SDK reconstruction, Data Catalog exports, dashboards, alerts, and model inputs. The point is to keep a stale market or incident window from looking like a normal result. Use Data quality for route-level quality checks, Reliability and gaps for workflow design, and WebSocket keep alive for stream recovery.

Escalation Notes

When a status check affects a customer workflow, include the route, symbol, data family, observed timestamp, expected freshness tolerance, request ID, and whether the issue is global or market-specific. That keeps support from treating a stale Lighter stream, a HIP-3 gap, and a general API outage as the same incident.

Get started

Market data

Get connected

Plans & limits

Status Signals

Client Policy

Status Check Checklist

Run Or Delay Rule

Escalation Notes

​Status Signals

​Client Policy

​Status Check Checklist

​Run Or Delay Rule

​Related Pages

​Escalation Notes

Status Signals

Client Policy

Status Check Checklist

Run Or Delay Rule

Related Pages

Escalation Notes