Document or specify how a service could implement a health check

[susheel]

Document or specify how a service could implement a health check (/healthz) which is especially important for ephemeral services and for service registries to rank services

[arendon]

I would propose that we separate concerns. The info endpoint may provide information of where the health endpoint may be called. The health endpoint may be an additional part of a spec for generating a network of integrate-able endpoints.

[susheel]

+1 Agree.

I think the spec could have an additional object that provides a number of probes if available:

{
  ...
  "probes": {
    "health": "/healthz",
    "metrics": "/metrics"
  }
  ...
}

This would be especially important for integration with the service registry

[jrambla]

In the ELIXIR Services Network specification we left that part for the next iteration, however, we designed it in a way that 1) the service should be able to answer autonomously, but granted registries can requests the stats, thus having a more comprehensive view of the network, and provide requesting services with a more useful and efficient view of what is in the network.
Practical example: You are a Beacon Aggregator (BA) service (a Beacon Network, old nomenclature), you request the corresponding Service Registry (SR) about the Beacons in the network in order to query them. The SR can simply provide a list of Beacons or complement that with the information about which ones are up or down, e.g.