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

> Tell whether the 0xArchive REST API and WebSocket service are up, follow incidents, and decide whether scheduled work should run, wait, or escalate.

Tell whether the 0xArchive service is up, and decide whether scheduled work should run, wait or be escalated. Whether one market's window is safe to use is a separate check, on [Data quality](/data-quality).

## Status signals

| Signal | What it tells you |
| - | - |
| [Public status page](https://0xarchive.io/status) | REST and WebSocket health, a coarse coverage summary, and public symbol counts, without a key |
| `GET /health` | Whether the REST API is reachable. Public, and it does not check an API key |
| `/v1/data-quality/status` | Overall service and ingestion state (`status`, `updated_at`), state by venue and data type, and the number of `active_incidents` |
| `/v1/data-quality/incidents` | Current and past incidents; filter with `status`, such as `open` or `investigating`, and `exchange` |
| `/v1/data-quality/latency` | Freshness and latency measurements |
| `/v1/data-quality/sla` | Service-level reporting by month |
| `/v1/status/coverage` | A public, coarse coverage and status summary, cached for five minutes |

`GET /health` returns `{"service":"0xarchive-api","status":"ok"}` with the request ID in the `x-request-id` header. The data-quality routes and `/v1/status/coverage` return their own fields at the top level, next to `success: true` and `meta.request_id`, unless you send the [version header](/conventions#versioning). A WebSocket client sees an interruption as a closed connection; reconnect and resubscribe as described in [WebSocket keep-alive](/websocket/keep-alive).

A healthy service can still return data that is stale for one job, and a degraded sub-state does not mean every route is unusable. Use the service signals to learn whether a broad issue is known, and the [Data quality](/data-quality) checks to decide about one market and window.

## Run, delay or escalate

End every status check in one explicit decision, and store it with the output of the job it gated:

| Decision | When to use it |
| - | - |
| Continue | Service health is inside the job's tolerance. Run the job and keep the check result with its output. |
| Narrow | One venue, market type or window is affected. Reduce the scope and record what you excluded. |
| Delay | The service is degraded or an open incident covers the data the job needs. Stop and retry after the next scheduled check. |
| Mark output | The job can tolerate the issue but its reader must see it. Attach the incident or status state to the output. |
| Escalate | The issue blocks a customer workflow or repeats across checks. Contact support with the details below. |

Use the same rule for REST pulls, WebSocket replay, SDK reconstruction, exports, dashboards, alerts and model inputs, so an outage never looks like a normal result.

## What to send support

Include the route or channel, symbol, data type, the UTC time of the check and the latest timestamp the data returned, the tolerance the job needs, the status code, `error_code` and request ID, and whether the issue affects one market or every request. That lets support tell a stale Lighter stream, a HIP-3 gap and a general outage apart.

## Next step

When the service is up, check whether one market's window is safe to use with [Data quality](/data-quality#check-one-window-before-use).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.