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.Documentation Index
Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
Use this file to discover all available pages before exploring further.
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.
Status Check Packet
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 |
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 |