New /health endpoint for indexer

[LexLuthr]

Status states

The API should define only three top-level states:

• green
• yellow
• red

The exact rules for assigning these states should be decided as part of this issue, but the intended meaning is:

green

The service is healthy. Backend indexers are reachable, queries are succeeding, and the service can be treated as operational by automated clients.

yellow

The service is degraded but partially usable. This may happen when some backend indexers are unhealthy, query latency is elevated, ingestion is delayed, or responses may be partial. Automated clients may continue using the service, but should treat the result as degraded.

red

The service is unavailable or unreliable enough that automated clients should not depend on it. This may happen when all required backend indexers are failing, the API is unreachable, queries are consistently timing out, or monitoring cannot verify service health.

State transition inputs to define

This issue should decide which signals are used to derive the state, for example:

• backend/indexer reachability
• query success rate
• query latency
• freshness/staleness of backend indexers
• ingestion health
• timeout rate
• whether responses are complete or partial
• monitoring freshness
• whether the status system itself has stale data

Backend status aggregation

Since cid.contact may be backed by multiple indexers, the API should expose individual backend statuses and a derived top-level status.

Example:

{
  "status": "yellow",
  "checkedAt": "2026-05-20T00:00:00Z",
  "indexers": [
    {
      "name": "indexer-a",
      "status": "green",
      "checkedAt": "2026-05-20T00:00:00Z"
    },
    {
      "name": "indexer-b",
      "status": "red",
      "checkedAt": "2026-05-20T00:00:00Z",
      "reason": "query_timeout"
    }
  ]
}

Open decisions

1. Which indexer affect overall status?
2. Should we tune it to PDP or general requirements?
3. State transition inputs to define

[willscott]

what is the concrete ask here vs https://status.cid.contact/
and in particular the json status feed it uses to render: https://status.cid.contact/api/getMonitorList/WzLl2t6G1O?page=1&_=1779277502005