Login 24/7 Support Community

Liveness health check

Overview

Health checks are extremely important in determining the status of an application - in this instance, the Tyk Gateway. Without them, it can be hard to know the actual state of the Gateway.

Depending on your configuration, the Gateway could be using a few components:

  • The Tyk Dashboard.
  • RPC
  • Redis (compulsory).

Any of these components could go down at any given point and it’d be great to understand if the Gateway is currently usable or not. A good usage of the health check endpoint is for the configuration of a load balancer to multiple instances of the Gateway or as a Kubernetes liveness probe.

Note

Health check is implemented as per the Health Check Response Format for HTTP APIs RFC

An example of the response from this API is as follows:

{
  "status": "pass",
  "version": "v3.1.1",
  "description": "Tyk GW",
  "details": {
    "redis": {
      "status": "pass",
      "componentType": "datastore",
      "time": "2020-05-19T03:42:55+01:00"
    },
    "dashboard": {
      "status": "pass",
      "componentType": "system",
      "time": "2020-05-19T03:42:55+01:00"
    },
    "rpc": {
      "status": "pass",
      "componentType": "system",
      "time": "2020-05-19T03:42:55+01:00"
    }
  }
}

If one of the components is having issues, status will change to “warn”, if all of them having issues status will be “fail”.

Configure health check

By default, the liveness health check is going to run on the /hello path. But it can be updated to any value by:

health_check_endpoint_name: "status"

Note

This will make the health check available on /status instead