interface Check<T = any> {
    affectedEndpoints?: string[];
    componentId: string;
    componentType?: string;
    links?: { about?: string; related?: string; self?: string };
    observedUnit?: string;
    observedValue?: T;
    output?: string | string[];
    status: "pass" | "fail" | "warn";
    time?: string;
    [x: string]: any;
}

Type Parameters

  • T = any

Indexable

  • [x: string]: any

    Any other desired property

Properties

affectedEndpoints?: string[]

A JSON array containing URI Templates as defined by [RFC6570]. This field SHOULD be omitted if the "status" field is present and has value equal to "pass". A typical API has many URI endpoints. Most of the time we are interested in the overall health of the API, without diving into details. That said, sometimes operational and resilience middleware needs to know more details about the health of the API (which is why "checks" property provides details). In such cases, we often need to indicate which particular endpoints are affected by a particular check's troubles vs. other endpoints that may be fine.

componentId: string

Unique identifier of an instance of a specific sub-component/dependency of a service. Multiple objects with the same componentID MAY appear in the details, if they are from different nodes.

componentType?: string

SHOULD be present if componentName is present. Type of the component. Could be one of:

  • Pre-defined value from this spec. Pre-defined values include:
    • component
    • datastore
    • system
- 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).
links?: { about?: string; related?: string; self?: string }

An array of objects containing link relations and URIs [RFC3986] for external links that MAY contain more information about the health of the endpoint. Per web-linking standards [RFC5988] a link relationship SHOULD either be a common/registered one or be indicated as a URI, to avoid name clashes. If a “self” link is provided, it MAY be used by clients to check health via HTTP response code, as mentioned above.

observedUnit?: string

SHOULD be present if metricValue is present. Could be one of:

  • 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).
observedValue?: T

Could be any valid JSON value, such as: string, number, object, array or literal

output?: string | string[]

Raw error output, in case of “fail” or “warn” states. This field SHOULD be omitted for “pass” state.

status: "pass" | "fail" | "warn"
time?: string

The date-time, in ISO8601 format, at which the reading of the metricValue was recorded. This assumes that the value can be cached and the reading typically doesn’t happen in real time, for performance and scalability purposes.