containers
as the host. This is not a problem for most applications but for those that only allow the use of certain hosts, such as applications built with Django that use ALLOWED_HOSTS
, this may result in non-200 responses. These applications will need to exempt hostname checking or add containers
to the list of allowed hosts on /healthcheck
.200 OK
HTTP response. Any other response will be considered a failure.
Strict Health Checks are useful if you’re doing further checking in your App to validate that it’s up and running.
To enable Strict Health Checks, set the STRICT_HEALTH_CHECKS
Configuration variable on your App to the value true
. This setting will apply to all Endpoints associated with your App.
200 OK
responses, so be careful with e.g. SSL redirections in your App that could cause your App to respond to the health check with a redirect, such as Rails’ config.force_ssl = true
. Overall, we strongly recommend verifying your logs first to check that you are indeed returning 200 OK
on /healthcheck
before enabling Strict Health Checks./healthcheck
, otherwise, it is simply performed at /
. In either case, the request is sent to the Container Port for the Endpoint.
RELEASE_HEALTHCHECK_TIMEOUT
Configuration variable on your App.
This variable must be set to your desired timeout in seconds. Any value from 0 to 900 (15 minutes) seconds is valid (we recommend that you avoid setting this to anything below 1 minute).
You can set this variable using the aptible config:set
command:
/healthcheck
. A healthy Container must respond with 200 OK
HTTP response if Strict Health Checks are enabled, or any status code otherwise. See Endpoint Logs for information about how Runtime Health Checks error logs can be viewed, and Health Checks Failed dealing with failures.
/healthcheck
coming from Aptible: they’ll have the X-Aptible-Health-Check
header set.