HTTP Probes

HTTP probes (health checks) are essential for ensuring smooth operation and transitions during rollouts. Quave ONE supports three types of probes: Readiness, Liveness, and Startup.

The readiness and liveness probes are the ones every app uses. The startup probe is optional and off by default — see Startup Probe below.

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 ONE 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.

The startup probe is optional and off by default. It is an extra gate in front of readiness, so every rollout wave has to wait for it before the new container can take traffic. Most apps do not need it: a readiness probe that only answers when the app is really ready already covers the slow-start case. Enable the startup probe only when your app needs a distinct slow-start gate — for example when it has a long migration or warm-up step and you want a longer, separate budget for it before the liveness probe can restart the container.

Basic mode never configures a startup probe. To use one, switch to advanced mode and enable Enable startup probe.

Configuration Modes

Basic Mode (Default)

In basic mode, you configure a single path that is used for the readiness and liveness probes. Basic mode never configures a startup probe.

1. Open the App and select HTTP Probes in its section navigation.
2. Enable the Enable HTTP probes checkbox.
3. Enter the health check path (e.g., /health or /healthz).
4. 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 the readiness and liveness probes with:
   • Path: The HTTP endpoint to check (e.g., /health, /ready, /started)
   • Period Seconds: How often to perform the probe, between 1 and 300 seconds
   • Failure Threshold: Number of consecutive failures before taking action, between 1 and 120
4. Optionally enable Enable startup probe and configure the startup probe with the same three fields.

Note: When advanced mode is enabled, the readiness and liveness probes each require all three fields. The startup probe fields are only required when the startup probe is enabled.

Accepted values

Field	Minimum	Maximum
periodSeconds	1	300
failureThreshold	1	120

Values outside these bounds are rejected by the dashboard, the Public API and the MCP tools.

Default Probe Values

When using basic mode, the default values for the readiness and liveness probes are:

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

No startup probe is configured in basic mode.

How It Works

Here's how the HTTP probes function:

• The readiness and liveness probes start after a platform initial delay of 5 seconds.
• The startup probe, when enabled, starts probing immediately (initial delay 0 seconds) at its configured period.
• Each probe then 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

The startup budget is therefore periodSeconds × failureThreshold for the startup probe and 5s + periodSeconds × failureThreshold for readiness and liveness.

Rollouts and probes

"Blue/Green deploy" in the App's Container Settings currently means a Kubernetes rolling update with 25% max surge and 25% max unavailable — not a second full stack that is swapped in at once. The number of waves follows from that: batches are ceil(25% of replicas) new containers at a time with floor(25% of replicas) allowed to be unavailable, so 3 replicas roll out in 3 waves and 4 or more replicas roll out in 2 waves.

Every probe that has to pass before a new container can take traffic is paid once per wave, which is why the startup probe is opt-in.

How to Disable HTTP Probes

To disable HTTP probes:

1. Open the App's HTTP Probes section and uncheck Enable HTTP probes.
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
  }
}

Advanced Mode with the Startup Probe

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