With Counterparty, we evaluate liveness based on whether the API port is open to TCP connections; we evaluate readiness with a healthz endpoint like so:
~ > http https://signet.counterparty.io:34000/healthz
HTTP/1.1 200 OK
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 33
Content-Type: application/json
Date: Wed, 05 Nov 2025 12:07:43 GMT
Server: nginx/1.25.5
X-Bitcoin-Height: 277007
X-Counterparty-Height: 277007
X-Counterparty-Image-Tag: v11.0.3
X-Counterparty-Ready: True
X-Counterparty-Version: 11.0.3
X-Ledger-State: Following
{
"result": {
"status": "Healthy"
}
}
We should also support these HTTP headers, I think.
The important thing for a readiness check of course is that it check whether the service is actually caught up with Bitcoin. Counterparty does a good job with this, with HTTP error codes, status field, etc. so the port is open to TCP initially but you only get a 200 back when it's caught up—otherwise it's a 503.
With Counterparty, we evaluate liveness based on whether the API port is open to TCP connections; we evaluate readiness with a
healthzendpoint like so:We should also support these HTTP headers, I think.
The important thing for a readiness check of course is that it check whether the service is actually caught up with Bitcoin. Counterparty does a good job with this, with HTTP error codes, status field, etc. so the port is open to TCP initially but you only get a
200back when it's caught up—otherwise it's a503.