Skip to main content

HTTP Health Check

To ensure smooth operation and transitions during Blue/Green deployments, it's essential to configure a custom HTTP health check in your App Settings.

Importance of HTTP Health Checks​

Configuring an HTTP health check is crucial for the following reasons:

  • Preventing the replacement of old containers when new ones are not ready to handle requests.
  • Ensuring that your old containers are not turned off while the new containers are still initializing.

Defining the Path​

We recommend adding a GET endpoint within your app that is fully prepared to accept new requests. The /health endpoint is a suitable choice. It should verify the proper functioning of critical resources like databases, ensuring they are connecting and responding as expected.

The Path field should begin with a forward slash (/) and should not include the domain name. By default, we set it to / for new apps.

Default Probe Values​

The current default values for the readiness probe and liveness probe are as follows:

  • Initial delay: 5 seconds
  • Period: 10 seconds
  • Failure threshold: 12 attempts

How It Works​

Here's how the HTTP health check functions:

  • Five seconds after the container is created, the health check begins testing the specified PATH.
  • The health check continues to retry every 10 seconds while the container is running.
  • If there are twelve consecutive unsuccessful trials, the container is automatically restarted.

Sample HTTP Health Check

Readiness Probe: A readiness probe is a mechanism to determine if a container within a pod is ready to start accepting traffic. It's used to indicate when an application or service inside the container has fully initialized and is prepared to handle incoming requests. If the readiness probe fails, the container is temporarily removed from the pool of endpoints that serve traffic. Once the probe succeeds, the container is added back to the pool. This is useful for scenarios where you want to make sure that a container is fully operational before it starts serving requests, preventing issues like prematurely routing traffic to an application that is still starting up.

Liveness Probe: A liveness probe is a mechanism to determine if a container is alive and functioning as expected. It checks the health of an application or service within the container during its runtime. If the liveness probe fails, zCloud will automatically restart the container, assuming that the application inside has encountered an issue or has become unresponsive. Liveness probes are used to maintain the overall health and reliability of the application, ensuring that any failures or crashes are quickly addressed by restarting the container.

These probes are fundamental for maintaining the stability and reliability of applications deployed in our clusters, ensuring that only healthy containers are serving traffic and automatically recovering from issues when they arise.

How to Temporarily Disable the Health Check​

To temporarily disable the health check, follow these steps:

  1. Set the Health Check Path field on your App page to an empty string (leave the field blank).
  2. Save the changes.
  3. Navigate to your desired app environment and click on "Apply Changes".

Once the deployment is complete, the health check will not run again as the path is not informed.

While we don't recommend this option, it can be helpful in certain cases, such as when dealing with long-running tasks in technologies like Node.js. In such scenarios, the event-loop may become blocked, causing the health check to incorrectly identify the app environment as down and trigger a container restart.