Backend Keepalive enabled automatically (DO Load Balancer)

Quick but important framing: of your four questions, #2–#4 (the change timestamp/history for your load balancers, node replacements, and whether 502s were seen on your LBs) are account-specific audit data. Nobody in the community can confirm those — only DigitalOcean support with access to your account and internal logs can. So the honest answer is: open a support ticket for those, and reference the specific LB IDs. What I can help with is the general behavior and how to pull your own change history.

On #1 — does DO auto-enable Backend Keepalive?

The documented default for enable_backend_keepalive is false, and I’m not aware of any published changelog where DigitalOcean flipped it to true on existing load balancers during a migration. So “it enabled itself” would be unusual and is worth support confirming rather than assuming.

Before concluding it changed on its own, rule out the common culprits — in my experience these are what actually flip LB settings silently:

• Infrastructure-as-code drift. If these LBs are (or ever were) managed by Terraform, Pulumi, or the DO Kubernetes CCM, a config change + apply can toggle enable_backend_keepalive without anyone clicking it in the UI. For K8s LBs specifically, the setting is driven by the service.beta.kubernetes.io/do-loadbalancer-enable-backend-keepalive annotation — a manifest change would push it.
• API/doctl automation. Any doctl compute load-balancer update or API call that re-sends the LB config must include the full spec; a script that omits a field can reset it. Check your CI/CD and any cron/automation that touches LBs.
• A teammate or a UI re-save. Editing an LB in the control panel and hitting save re-submits the whole config.

How to pull the real state and (some) history yourself

1. Current authoritative value — hit the API directly:

   curl -X GET \
     -H "Authorization: Bearer $DO_TOKEN" \
     "https://api.digitalocean.com/v2/load_balancers/<LB_ID>"
   

   Look at enable_backend_keepalive in the response.
2. If IaC-managed — run terraform plan (or pulumi preview). If the tool wants to change the value back, that tells you the drift direction and who/what is authoritative.
3. Git history — git log -p on your Terraform/Pulumi/K8s manifests filtered for keepalive will show exactly when and by whom the value changed in code.
4. DO team activity — check the Account → Activity / audit log and, if you’re on a Team, ask whether anyone re-saved the LBs recently.

For the support ticket

Give them: the LB IDs, the region, your internal screenshot date showing it disabled, and the approximate window you noticed it enabled. Then ask specifically for:

• the change history of enable_backend_keepalive for those LB IDs,
• any node replacements / backend connection-handling updates in that window,
• backend 5xx/502 metrics for those LBs around the incident time.

Support can pull all four; the community can’t.

One practical note: since keepalive being on generally improves requests/sec and latency and reduces TCP churn, unless you’re seeing actual errors you may be fine leaving it enabled — but I’d still get the audit trail so you know how it changed. If you were seeing 502s, that’s a separate backend-connection-reuse issue worth digging into (idle-timeout mismatch between the LB and your app server is the usual cause).

Hope that helps narrow it down!