Checks: { [entry in CheckEntry]: Check<T>[] }

The “checks” object MAY have a number of unique keys, one for each logical sub-components. Since each sub-component may be backed by several nodes with varying health statuses, the key points to an array of objects. In case of a single-node sub-component (or if presence of nodes is not relevant), a single-element array should be used as the value, for consistency. The key identifying an element in the object should be a unique string within the details section. It MAY have two parts: {componentName}:{metricName}, in which case the meaning of the parts SHOULD be as follows:

  • componentName: Human-readable name for the component. MUST not contain a colon, in the name, since colon is used as a separator
  • metricName: Name of the metrics that the status is reported for. MUST not contain a colon, in the name, since colon is used as a separator and can be one of:
    • Pre-defined value from this spec. Pre-defined values include:
      • utilization
      • responseTime
      • connections
      • uptime
    • A common and standard term from a well-known source such as schema.org, IANA or microformats.
    • A URI that indicates extra semantics and processing rules that MAY be provided by a resource at the other end of the URI. URIs do not have to be dereferenceable, however. They are just a namespace, and the meaning of a namespace CAN be provided by any convenient means (e.g. publishing an RFC, Swagger document or a nicely printed book).

Type Parameters

  • T = any