> ## 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 monitoring

> Connect the 0xArchive public status page, health checks, data-quality routes, incidents, freshness, and operational runbooks.

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](/rest-api)                                 |
| WebSocket liveness | Whether stream service checks are healthy                      | [WebSocket](/websocket)                               |
| Coverage           | Which venue families, symbols, and data families are available | [Data availability](/core-concepts/data-availability) |
| Incidents          | Known interruptions or degraded windows                        | [Data gaps](/core-concepts/data-gaps)                 |
| Freshness          | Whether latest data is inside tolerance                        | [Data quality](/data-quality)                         |
| Request IDs        | Support and debugging across failed probes                     | [Responses](/responses), [Errors](/errors)            |

## Client Policy

<Steps>
  <Step title="Separate service health from data trust">
    A healthy service can still return data that is stale for a specific job.
  </Step>

  <Step title="Check the relevant family">
    Inspect the venue family, symbol, and data family your workflow needs, not only global status.
  </Step>

  <Step title="Record the decision">
    Store status, coverage, incident, freshness, and request-ID context with downstream output.
  </Step>

  <Step title="Fail visibly">
    If status or freshness is outside tolerance, stop or mark the output instead of silently continuing.
  </Step>
</Steps>

## 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.

## Related Pages

Use [Data quality](/data-quality) for route-level quality checks, [Reliability and gaps](/guides/reliability-and-gaps) for workflow design, and [WebSocket keep alive](/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.