Set Up Liveness Health Checks
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).
- MongDB or SQL
-
Tyk Pump
Health check is implemented as per the Health Check Response Format for HTTP APIs RFC
Status Levels
The following status levels can be returned in the JSON response.- pass: Indicates that all components required for the Gateway to work 100% are available, and there is no impact on your traffic.
- warn: Indicates that one of the components is having an outage but your Gateway is able to keep processing traffic. The impact is medium (i.e. no quotas are applied, no analytics, no RPC connection to MDCB).
- fail: Indicates that Redis AND the Tyk Dashboard are unavailable, and can and indicate other failures. The impact is high (i.e. no configuration changes are available for API/policies/keys, no quotas are applied, and no analytics).
Configure health check
By default, the liveness health check runs on the/hello
path. But
it can be configured to run on any path you want to set. For example:
/status
instead of /hello
.
Refresh Interval
The Health check endpoint will refresh every 10 seconds.
HTTP error code
The Health check endpoint will always return a HTTP 200 OK
response if the polled health check endpoint is available on your Tyk Gateway. If HTTP 200 OK
is not returned, your Tyk Gateway is in an error state.
For MDCB installations the /hello
endpoint can be polled in either your Management or Worker Gateways. It is recommended to use the /hello
endpoint behind a load balancer for HA purposes.
Health check examples
The following examples show how the Health check endpoint returnsPass Status
The following is returned for apass
status level for the Open Source Gateway: