Backend Keepalive enabled automatically (DO Load Balancer)

Question

Our load balancers were created around 2021 with Backend Keepalive disabled, according to our internal screenshots. Today both staging and production load balancers show Backend Keepalive enabled, but we do not recall enabling it.

Can you confirm:

Whether DigitalOcean ever automatically enabled Backend Keepalive for existing load balancers during a platform migration or product update?
The timestamp/history of changes to enable_backend_keepalive for these load balancers.
Whether there were any load balancer node replacements or backend connection handling updates recently.
Whether backend connection errors / 502s were observed for these load balancers around the incident time.

KFSys · Answer

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

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.

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

Bobby · Answer

Hi there,

This is not something the community can really confirm since it requires access to your account history and DigitalOcean’s internal change logs.

DigitalOcean has made platform-level improvements to load balancers over the years so it is possible a migration or default change updated settings on existing resources. For all four of your questions, a support ticket is the right path. Reference both load balancer IDs and the timeframe you noticed the change, and ask specifically for the history on enable_backend_keepalive. The team should be able to give you a clear answer.

On the practical side, Backend Keepalive is generally a good thing since it reduces connection overhead between the load balancer and your backends. If you do suspect it caused any issues, worth checking that your backend application’s keepalive timeout is configured longer than the load balancer’s to avoid premature connection resets.

alexdo · Answer

One thing you can self-check right now though: the current live value, without waiting on a ticket.

doctl compute load-balancer get <load-balancer-id>

That returns the full current config including enable_backend_keepalive, so you can at least confirm what’s live today while support digs into the history. Worth checking your deploy scripts or Terraform state too before assuming it was DigitalOcean’s side, an update call that resends the full LB spec without that field explicitly set to false can flip it back on, that’s a common way this happens without anyone touching it directly in the UI.

Regards