Using Application Health Checks

Page last updated:

About Application Health Checks

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.

How Application Health Checks Work

The following table describes how application health checks work in Cloud Foundry.

Stage Description
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 port health check.
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.

Application Health Check Configuration

This section provides information about the configuration of application health checks.

Health Check Types

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 HTTP 200 response http. The HTTP health check does a GET request to the configured HTTP endpoint. When the health check receives an HTTP 200 response, the app is declared healthy. If possible, HTTP is the recommended health check mechanism. The advantage of using an HTTP health check is that a healthy HTTP response ensures that the web app is ready to serve HTTP requests. The configured endpoint must respond within 1 second to be considered healthy.
can receive TCP connections (including HTTP web applications) port. A port health check makes a TCP connection to the port or ports configured for the application. For applications with multiple ports, a health check monitors each port. If you do not specify a health check type for your application, then port is used. The TCP connection must be established within 1 second to be considered healthy.
does not support TCP connections (for example, a worker) process. For a process health check, Diego ensures that any process declared for the app stays running. If the process exits, Diego tears down the app instance.

Health Check Timeouts

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.

Health Check HTTP Endpoints

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.

How to Configure the Health Check for Your Application

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.

Create a pull request or raise an issue on the source for this page in GitHub