Description

This rule checks that App Platform application components have health checks configured so the platform can determine when an instance is ready to serve traffic and can detect and replace unhealthy instances. App Platform uses health checks as readiness probes and sends failure notifications to the account email.

iCompaas inspects each app component's spec for a defined health_check block (for HTTP components, an http_path readiness endpoint together with sensible interval and threshold settings). App Platform applies a default health check, but relying on the default TCP-only probe can miss application-level failures that a proper HTTP readiness path would catch.

Remediation is to implement a lightweight readiness endpoint in the application, point the App Platform health_check at it, and tune the interval and failure threshold appropriately.

  • App components with no explicit health_check block in the app spec.

  • HTTP services relying on a default TCP probe instead of an http_path readiness check.

  • Health checks with thresholds so loose that failures are detected slowly.

Rationale

Without an accurate readiness/health check, App Platform can route traffic to an instance that has started its process but is not actually able to serve requests, or keep sending traffic to a hung instance. Users then see errors or timeouts until someone notices and intervenes.

An HTTP health check that reflects true readiness lets the platform hold traffic until the instance is ready and automatically restart or replace instances that fail, improving availability without manual intervention.

  • Readiness probes prevent traffic from reaching not-yet-ready instances.

  • Automatic detection and replacement of unhealthy instances reduces downtime and manual toil.

Impact

Pros:

  • Traffic is withheld from instances until they can actually serve it.

  • Hung or crashed instances are detected and restarted/replaced automatically.

  • Failure notifications alert the team to persistent problems.

Cons:

  • Requires building and maintaining a readiness endpoint that reflects real health.

  • Misconfigured thresholds/timeouts can cause false-positive restarts (flapping) or slow detection.

  • A health path that does expensive work can add load or itself become a failure point.

Default Value

App Platform applies a default health check to components (a TCP check on the component's http port); an HTTP path-based readiness check is not used unless you configure http_path in the component's health_check.

Pre-Requisite

  • A DigitalOcean Control Panel account with a role that can edit the App Platform app.

  • A DigitalOcean API token, or doctl authenticated via 'doctl auth init'.

  • A known, lightweight readiness endpoint (for example /healthz) in the application.

Remediation

Test Plan

Using the DigitalOcean Control Panel:

  1. Log in to cloud.digitalocean.com and open Apps, then select the app.

  2. Open Settings and select the component (service/worker).

  3. Open the Health Checks section and review the configured type (HTTP or TCP), path, port, and thresholds.

  4. Repeat for each component that serves traffic.

  5. Pass: Each HTTP-serving component has a health check with an http_path readiness endpoint and appropriate interval/thresholds.

  6. Fail: A component has no configured health check beyond the default, or an HTTP service lacks an http_path readiness check.

Using doctl or the API:

Retrieve the app spec and inspect each component's health_check.

doctl apps list --format ID,Spec.Name
doctl apps spec get <app-id>
curl -s -X GET 'https://api.digitalocean.com/v2/apps/<app-id>' -H 'Authorization: Bearer $DIGITALOCEAN_TOKEN' | jq '.app.spec.services[] | {name, health_check}'

Pass: each serving component's spec includes a health_check with http_path set (plus reasonable period/timeout/failure_threshold). Fail: health_check is absent, or an HTTP service defines no http_path.

Implementation Steps

Using the DigitalOcean Control Panel:

  1. Add a lightweight readiness endpoint to the application (for example GET /healthz returning 200 when ready).

  2. In the Control Panel open Apps > the app > Settings > the component > Health Checks and click Edit.

  3. Set Type to HTTP, enter the http path and port, and set Initial Delay, Period, Timeout, Success Threshold, and Failure Threshold.

  4. Save; App Platform redeploys the component with the new health check.

  5. Verify the component reports healthy and that failures trigger restarts as expected.

Using doctl or the API:

Update the app spec (with the health_check block added) via doctl or the API.

doctl apps update <app-id> --spec app.yaml
curl -s -X PUT 'https://api.digitalocean.com/v2/apps/<app-id>' -H 'Authorization: Bearer $DIGITALOCEAN_TOKEN' -H 'Content-Type: application/json' -d @app-update.json

Backout Plan:

  1. Keep the previous app spec (for example the output of 'doctl apps spec get <app-id>') before editing.

  2. To revert, re-apply the saved spec with 'doctl apps update <app-id> --spec previous-app.yaml' (or PUT the previous spec to /v2/apps/<app-id>).

  3. If a new health check causes flapping, relax the failure_threshold/timeout or restore the prior configuration and redeploy.

References:

  1. Manage App Platform Health Checks

  2. App Platform App Spec reference

  3. doctl apps