Using Application Health Checks
Page last updated:
An application health check is a monitoring process that continually checks the status of a running Cloud Foundry application.
When deploying an app, a developer can configure the health check type (port, process, or HTTP), a timeout for starting the application, and an endpoint (for HTTP only) for the application health check.
Application health checks function as part of the app lifecycle managed by Diego architecture.
The following table describes how application health checks work in Cloud Foundry.
|1||Application developer deploys an app to Cloud Foundry.|
|2||When deploying the app, the developer specifies a health check type for the app and optionally, a timeout. If the developer does not specify a health check type, then the monitoring process defaults to a
|3||Cloud Controller stages, starts, and runs the app.|
|4||Based on the type specified for the app, Cloud Controller configures a health check that runs periodically for each application instance.|
|5||When Diego starts an app instance, the application health check runs every 2 seconds until a response indicates that the app instance is healthy or until the health check timeout has elapsed. The 2-second health check interval is not configurable.|
|6||When an app instance becomes healthy, its route is advertised, if applicable. Subsequent health checks are run every 30 seconds once the app becomes healthy. The 30-second health check interval is not configurable.|
|7||If a previously healthy app instance fails a health check, Diego then considers that particular instance to be unhealthy. As a result, Diego tears down the instance, and then reschedules it. The teardown of the app instance is reported back to the Cloud Controller as a crash event.|
|8||When an app instance crashes, Diego immediately attempts to restart the app instance several times. After three failed restarts, CF waits thirty seconds before attempting another restart. The wait time doubles each restart until the ninth restart, and remains at that duration until the 200th restart. After the 200th restart, CF stops trying to restart the app instance.|
This section provides information on the configuration of application health checks.
The following table describes the types of health checks available for apps and when best to use them:
|If your app:||Then use this type of health check:|
|can provide an
|can receive TCP connections (including HTTP web applications)||
|does not support TCP connections (for example, a worker)||
The value configured for the health check timeout is the amount of time allowed to elapse between starting up an app and the first healthy response from the app. If the health check does not receive a healthy response within the configured timeout, then the app is declared unhealthy.
In Pivotal Web Services, the default timeout is 60 seconds and the maximum configurable timeout is 180 seconds.
Only used by
http type, this configuration specifies the path portion of a URI that must be served by the app and return
HTTP 200 when the app is healthy.
You can configure a health check type, application start timeout and HTTP endpoint for your application by using the Cloud Controller API.
To set the type of health check for your application, you can specify a value in the
health-check-type field of your application manifest file.
You can change the health check configuration of a deployed app, but you must restart the app for the changes to take effect.