Skip to main content

HTTP Probes

HTTP probes (health checks) are essential for ensuring smooth operation and transitions during Blue/Green deployments. Quave Cloud supports three types of probes: Readiness, Liveness, and Startup.

Importance of HTTP Probes​

Configuring HTTP probes 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.
  • Automatically recovering from container failures or unresponsive applications.

Probe Types​

Readiness Probe​

A readiness probe determines if a container is ready to start accepting traffic. It indicates when an application 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.

Liveness Probe​

A liveness probe determines if a container is alive and functioning as expected. It checks the health of an application during its runtime. If the liveness probe fails, Quave Cloud will automatically restart the container, assuming the application has encountered an issue or has become unresponsive.

Startup Probe​

A startup probe is used for containers that have slow startup times. It prevents the liveness and readiness probes from running until the startup probe succeeds. This is useful for applications that need extra time to initialize.

Configuration Modes​

Basic Mode (Default)​

In basic mode, you configure a single path that is used for all three probes (readiness, liveness, and startup).

  1. Enable the Enable HTTP probes checkbox in your App Settings.
  2. Enter the health check path (e.g., /health or /healthz).
  3. Save changes and apply to your environments.

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 should begin with a forward slash (/) and should not include the domain name. By default, we set it to / for new apps.

Advanced Mode (Individual Probe Configuration)​

For more control, you can configure each probe individually with different paths and timing settings.

  1. Enable the Enable HTTP probes checkbox.
  2. Enable the Different configuration for liveness, readiness and startup probes checkbox.
  3. Configure each probe with:
    • Path: The HTTP endpoint to check (e.g., /health, /ready, /started)
    • Period Seconds: How often to perform the probe (in seconds)
    • Failure Threshold: Number of consecutive failures before taking action

Note: When advanced mode is enabled, all 9 fields (3 probes x 3 fields) are required.

Default Probe Values​

When using basic mode, the default values for all probes are:

  • Path: / (root)
  • Period: 10 seconds
  • Failure threshold: 12 attempts

How It Works​

Here's how the HTTP probes function:

  • Shortly after the container is created, the probes begin testing the specified path(s).
  • Each probe continues to check at its configured interval (period seconds).
  • If a probe fails the configured number of times (failure threshold), the appropriate action is taken:
    • Readiness: Container removed from traffic pool
    • Liveness: Container restarted
    • Startup: Container marked as failed

Sample HTTP Health Check

How to Disable HTTP Probes​

To disable HTTP probes:

  1. Uncheck the Enable HTTP probes checkbox on your App page.
  2. Save the changes.
  3. Navigate to your desired app environment and click on "Apply Changes".

Once the deployment is complete, no probes will run for the containers.

While we don't recommend disabling probes, 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.

API Configuration​

You can also configure HTTP probes via the Public API or MCP tools.

Basic Mode Example​

{
  "appEnvId": "your-app-env-id",
  "enableHttpProbes": true,
  "healthCheckPath": "/health"
}

Advanced Mode Example​

{
  "appEnvId": "your-app-env-id",
  "enableHttpProbes": true,
  "isConfigurationByProbeEnabled": true,
  "readinessProbe": {
    "path": "/ready",
    "periodSeconds": 10,
    "failureThreshold": 3
  },
  "livenessProbe": {
    "path": "/health",
    "periodSeconds": 30,
    "failureThreshold": 5
  },
  "startupProbe": {
    "path": "/started",
    "periodSeconds": 5,
    "failureThreshold": 30
  }
}