Health probes in Azure Container Apps

Article
11/26/2024

Azure Container Apps health probes allow the Container Apps runtime to regularly inspect the status of your container apps.

You can set up probes using either TCP or HTTP(S) exclusively.

Container Apps supports the following probes:

Probe	Description
Startup	Checks if your application has successfully started. This check is separate from the liveness probe and executes during the initial startup phase of your application.
Liveness	Checks if your application is still running and responsive.
Readiness	Checks to see if a replica is ready to handle incoming requests.

For a full list of the probe specification supported in Azure Container Apps, refer to Azure REST API specs.

HTTP probes

HTTP probes allow you to implement custom logic to check the status of application dependencies before reporting a healthy status.

Configure your health probe endpoints to respond with an HTTP status code greater than or equal to 200 and less than 400 to indicate success. Any other response code outside this range indicates a failure.

The following example demonstrates how to implement a liveness endpoint in JavaScript.

const express = require('express');
const app = express();

app.get('/liveness', (req, res) => {
  let isSystemStable = false;
  
  // check for database availability
  // check filesystem structure
  //  etc.

  // set isSystemStable to true if all checks pass

  if (isSystemStable) {
    res.status(200); // Success
  } else {
    res.status(503); // Service unavailable
  }
})

TCP probes

TCP probes wait to establish a connection with the server to indicate success. The probe fails if it can't establish a connection to your application.

Restrictions

You can only add one of each probe type per container.
exec probes aren't supported.
Port values must be integers; named ports aren't supported.
gRPC isn't supported.

Examples

The following code listing shows how you can define health probes for your containers.

The ... placeholders denote omitted code. Refer to Container Apps ARM template API specification for full ARM template details.

ARM template
YAML

{
  ...
  "containers":[
    {
      "image":"nginx",
      "name":"web",
      "probes": [
        {
          "type": "liveness",
          "httpGet": {
            "path": "/health",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "liveness probe"
              }]
          },
          "initialDelaySeconds": 7,
          "periodSeconds": 3
        },
        {
          "type": "readiness",
          "tcpSocket": {
            "port": 8081
          },
          "initialDelaySeconds": 10,
          "periodSeconds": 3
        },
        {
          "type": "startup",
          "httpGet": {
            "path": "/startup",
            "port": 8080,
            "httpHeaders": [
              {
                "name": "Custom-Header",
                "value": "startup probe"
              }]
          },
          "initialDelaySeconds": 3,
          "periodSeconds": 3
        }]
    }]
  ...
}

...
containers:
  - image: nginx
    name: web
    probes:
      - type: liveness
        httpGet:
          path: "/health"
          port: 8080
          httpHeaders:
            - name: Custom-Header
              value: "liveness probe"
        initialDelaySeconds: 7
        periodSeconds: 3
      - type: readiness
        tcpSocket:
          port: 8081
        initialDelaySeconds: 10
        periodSeconds: 3
      - type: startup
        httpGet:
          path: "/startup"
          port: 8080
          httpHeaders:
            - name: Custom-Header
              value: "startup probe"
        initialDelaySeconds: 3
        periodSeconds: 3
...

The optional failureThreshold setting defines the number of attempts Container Apps tries to execute the probe if execution fails. Attempts that exceed the failureThreshold amount cause different results for each probe type.

Default configuration

If ingress is enabled, the following default probes are automatically added to the main app container if none is defined for each type.

Probe type	Default values
Startup	Protocol: TCP Port: ingress target port Timeout: 3 seconds Period: 1 second Initial delay: 1 second Success threshold: 1 Failure threshold: 240
Liveness	Protocol: TCP Port: ingress target port
Readiness	Protocol: TCP Port: ingress target port Timeout: 5 seconds Period: 5 seconds Initial delay: 3 seconds Success threshold: 1 Failure threshold: 48

If you're running your container app in multiple revision mode, after you deploy a revision, wait until your readiness probes indicate success before you shift traffic to that revision. In single revision mode, traffic is shifted automatically once the readiness probe returns a successful state.

A revision state appears as unhealthy if any of its replicas fails its readiness probe check, even if all other replicas in the revision are healthy. Container Apps restarts the replica in question until it is healthy again or the failure threshold is exceeded. If the failure threshold is exceeded, try restarting the revision, but it might mean the revision is not configured correctly.

If your app takes an extended amount of time to start (which is common in Java) you often need to customize the probes so your container doesn't crash.

The following example demonstrates how to configure the liveness and readiness probes in order to extend the startup times.

"probes": [
       {
        "type": "liveness",
        "failureThreshold": 3,
        "periodSeconds": 10,
        "successThreshold": 1,
        "tcpSocket": {
          "port": 80
        },
        "timeoutSeconds": 1
       },
       {
         "type": "readiness",
         "failureThreshold": 48,
         "initialDelaySeconds": 3,
         "periodSeconds": 5,
         "successThreshold": 1,
         "tcpSocket": {
           "port": 80
          },
          "timeoutSeconds": 5
       }]

Next steps

Application logging

Share via