Status signals
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. A WebSocket client sees an interruption as a closed connection; reconnect and resubscribe as described in 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 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:
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.