# Ensure App Platform Health Checks Are Configured

- Source: https://support.icompaas.com/support/solutions/articles/ensure-app-platform-health-checks-are-configured
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules)
- Last updated: 2026-08-13
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## 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](https://docs.digitalocean.com/products/app-platform/how-to/manage-health-checks/)
    
2.  [App Platform App Spec reference](https://docs.digitalocean.com/products/app-platform/reference/app-spec/)
    
3.  [doctl apps](https://docs.digitalocean.com/reference/doctl/reference/apps/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.