cf-app-health-check

Configuring CF App Health Checks with MTA

Table of Contents

• Official Documentation
• Overview
  • Picking a health-check-type
  • About health-check-interval
• Try it out
  • Deploy from directory
  • Build and deploy
  • Examine the result
  • Use Cases
  • Related Examples

This example shows how to configure Cloud Foundry application health checks through the MTA health-check-* parameters. Health checks determine when Cloud Foundry considers an app instance healthy after start and while it is running; misconfiguring them is a common cause of "app crashed" or "app never became healthy" failures on deploy.

Official Documentation

For general information about module parameters, see: SAP BTP Documentation - Module-Specific Parameters

For the underlying Cloud Foundry concept, see: Cloud Foundry Docs - Using Application Health Checks

Overview

Four MTA parameters cover the full health-check surface of a CF application:

Parameter	Purpose
health-check-type	How CF probes the app: http, port, or process
health-check-http-endpoint	HTTP path CF requests when health-check-type: http
health-check-timeout	Seconds CF waits for the app to become healthy after start
health-check-interval	Seconds between successive health checks while the app runs

Picking a health-check-type

Type	When to use it
http	The app serves HTTP and can respond with 2xx on a known path. Pair with health-check-http-endpoint.
port	The app listens on the port CF assigns ($PORT) but does not serve HTTP, or you don’t want to expose a health endpoint. Applied by default when health-check-type is not set.
process	The app is not network-facing (worker, one-off task). CF only checks that the process is alive.

About health-check-interval

health-check-interval maps to CF’s v3 process health_check.data.interval field and controls how often the liveness check runs after the app is up.

Try it out

Deploy from directory

This approach uses deployment descriptor mtad.yaml and ready application binaries appBits.zip:

$ cf deploy ./ -f ;

Build and deploy

This approach uses development descriptor mta.yaml and application binaries appBits.zip to build an MTAR archive:

$ mbt build -p cf -t . ;

The built MTAR is then deployed:

$ cf deploy cf.app.health.check_0.0.0.mtar -f ;

Note	See mta.yaml or mtad.yaml for the full parameter set.

Examine the result

List the deployed MTA

$ cf mta cf.app.health.check ;
Showing health and status for multi-target app cf.app.health.check in org **** / space **** as ****...
OK
Version: 0.0.0
Namespace:

Apps:
name                            requested state   instances   memory   disk   urls
my-health-checked-app-module    STARTED           1/1         19.6M    5.3M   orgname-spacename-my-health-checked-app-module.example.com

Verify the health check landed on the CF process

Inspect the health_check block on the app’s web process. All four values from the MTA descriptor should be reflected here:

$ cf curl "/v3/apps/$(cf app my-health-checked-app-module --guid)/processes" ;
{
  "resources": [
    {
      "type": "web",
      "instances": 1,
      "health_check": {
        "type": "http",
        "data": {
          "timeout": 180,
          "invocation_timeout": null,
          "interval": 15,
          "endpoint": "/index"
        }
      },
      ...
    }
  ]
}

If interval is null in the output despite being set in the descriptor, the deploy service version does not yet support the parameter.

Use Cases

Fast-recovering web app (frequent checks, short grace period):

health-check-type: http
health-check-http-endpoint: "/health"
health-check-timeout: 30
health-check-interval: 5

Slow-starting app that only needs to open a port:

health-check-type: port
health-check-timeout: 300
health-check-interval: 30

Background worker with no listening port:

health-check-type: process
health-check-timeout: 60

Related Examples

• Simple CF app example, managing app attributes & deploy parameters

• Managing CF app features with app-features parameter