# Ensure Health Checks Are Configured For Backend Resources - Source: https://support.icompaas.com/support/solutions/articles/ensure-health-checks-are-configured-for-backend-resources - 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 verifies that every DigitalOcean Load Balancer has an active health check configured against its backend targets so that unhealthy Droplets are automatically removed from rotation. On a DigitalOcean Load Balancer the health check is defined by a protocol (http, https, or tcp), a port, a path (for HTTP/HTTPS), and timing thresholds: check\_interval\_seconds, response\_timeout\_seconds, healthy\_threshold, and unhealthy\_threshold. The rule inspects each load balancer's health\_check object and confirms the probe targets a meaningful endpoint (an application path and port rather than a placeholder) with sensible interval and threshold values. Because DigitalOcean always applies a default health check, the emphasis is on confirming the check actually reflects application health rather than a port that is always open. Remediation is to point the health check at a real application health endpoint and port, and tune the interval and thresholds so failed backends are detected and removed promptly while avoiding flapping. - Load balancers whose health check path/port does not correspond to the application being served. - Health checks left on a generic TCP port-80 probe when the backend serves HTTPS only. - Interval or threshold values so high that a failed backend keeps receiving traffic for a long time. ## Rationale Without an accurate health check, a load balancer continues to distribute requests to a Droplet that has crashed, is returning errors, or has a degraded application even though the underlying port still accepts connections. A portion of users then receive failures or timeouts until an operator intervenes manually. An HTTP/HTTPS health check against an application path detects application-level failure, not just that a socket is open, and lets the load balancer remove and later restore backends automatically. Well-tuned intervals and thresholds balance fast failover against stability: too lax and outages persist; too aggressive and healthy nodes flap in and out of rotation under transient load. - Automatically removes failed or degraded backends from rotation, preserving availability. - Application-layer probes catch failures a bare TCP check would miss. - Automatic restoration returns recovered backends to service without manual action. ## Impact Pros: - Failed backends stop receiving traffic without operator intervention. - Users are shielded from partial outages caused by one bad Droplet. - Recovered backends rejoin rotation automatically once they pass again. Cons: - Requires the backend application to expose a reliable health endpoint. - Overly aggressive thresholds can eject healthy nodes during transient spikes. - Health-check requests add a small amount of load to each backend. ## Default Value DigitalOcean Load Balancers always have a health check; by default it uses HTTP on port 80 with path '/', a 10-second check interval, a 5-second response timeout, and threshold counts for marking a node healthy or unhealthy — so a check exists but may not match your application's real health endpoint. ## Pre-Requisite - A DigitalOcean account role that can view and edit Load Balancers. - doctl authenticated with a DigitalOcean API token (or $DIGITALOCEAN\_TOKEN exported). - Knowledge of the backend application's health endpoint (protocol, port, and path) that returns a success status when healthy. ## Remediation ### Test Plan Using the DigitalOcean Control Panel: 1. Sign in to cloud.digitalocean.com. 2. Go to Networking, then the Load Balancers tab, and select the load balancer. 3. Open the Settings tab and locate the Health Checks section. 4. Confirm the protocol, port, and path point at a real application endpoint (for example HTTPS on the app port and a /health path) rather than a placeholder. 5. Review the check interval, response timeout, and the healthy/unhealthy thresholds for reasonable values. 6. Pass: The health check targets the application's actual protocol/port/path and uses sensible interval and threshold values. 7. Fail: The health check still points at a generic port/path that does not reflect application health, or thresholds are so high that failed backends would keep serving traffic. Using doctl or the API: Inspect each load balancer's health\_check object. doctl compute load-balancer list --format ID,Name,HealthCheck doctl compute load-balancer get --format HealthCheck curl -s -X GET "https://api.digitalocean.com/v2/load\_balancers" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" | jq '.load\_balancers\[\] | {id, name, health\_check}' Pass: health\_check.protocol, port, and path correspond to the served application (HTTP/HTTPS check against the app's health path) with interval and thresholds appropriate for prompt failover. Fail: the health check targets an unrelated port/path or uses timings that let a failed backend keep receiving traffic. ### Implementation Steps Using the DigitalOcean Control Panel: 1. In the Control Panel, open Networking, then Load Balancers, and select the load balancer. 2. In the Settings tab, open the Health Checks section. 3. Set the protocol to HTTP or HTTPS (use TCP only when the backend is not HTTP-based), and set the port and path to the application's health endpoint. 4. Adjust the check interval, response timeout, and the healthy/unhealthy thresholds so failed nodes are detected quickly without flapping. 5. Save the changes and confirm the backend pool reports healthy after the check stabilizes. Using doctl or the API: Update the health\_check block via doctl or the API. doctl compute load-balancer update --health-check "protocol:http,port:80,path:/health,check\_interval\_seconds:10,response\_timeout\_seconds:5,healthy\_threshold:3,unhealthy\_threshold:3" curl -s -X PUT "https://api.digitalocean.com/v2/load\_balancers/" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"health\_check": {"protocol":"http","port":80,"path":"/health","check\_interval\_seconds":10,"response\_timeout\_seconds":5,"healthy\_threshold":3,"unhealthy\_threshold":3}}' ### Backout Plan: 1. Capture the existing health\_check values before editing (doctl compute load-balancer get --format HealthCheck). 2. If the new check wrongly marks healthy backends as down, re-run the update with the previous health\_check values. 3. Confirm the backend pool returns to healthy after reverting. 4. Re-tune incrementally rather than reverting entirely once the correct endpoint is confirmed. ## References: 1. [DigitalOcean Load Balancers API reference (health\_check fields and defaults)](https://docs.digitalocean.com/reference/api/reference/load-balancers/) 2. [DigitalOcean Load Balancers — Features (health checks)](https://docs.digitalocean.com/products/networking/load-balancers/details/features/) 3. [How to Manage Regional Load Balancers](https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage/) 4. [doctl compute load-balancer update](https://docs.digitalocean.com/reference/doctl/reference/compute/load-balancer/update/) ## 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.