# Self-Healing CI: Recovering a Load Balancer Warmup 502

> A 502 from a load balancer while new targets are warming up is a transient readiness blip, not a broken deploy. See the manual fix and how self-healing CI waits and retries.

Source: https://latchkey.dev/learn/self-healing-ci/self-healing-load-balancer-warmup-502  
Updated: 2026-06-26

A 502 from the load balancer while new targets are still registering is a warmup readiness blip, not a broken deploy -- once targets are healthy, the same request succeeds.

## What makes a failure safely retryable

Automatic retry is only correct for failures that are genuinely transient. Retrying a deterministic failure wastes minutes and hides a real defect, so the classification matters more than the retry mechanism.

- Safe to retry: network timeouts, registry 5xx, transient DNS failures, a service container that was not ready, a spot instance reclaimed mid-run.
- Not safe to retry: assertion failures, compile errors, lint violations, anything that fails identically on every attempt.
- Ambiguous, and worth investigating rather than retrying: out-of-memory kills, disk exhaustion, and flaky tests. These repeat under load and a retry only hides the trend.
- Always record that a retry happened. A pipeline that silently retries is a pipeline whose real failure rate you do not know.

## FAQ

### What causes Self-Healing CI: recovering a load balancer warmup 502?

A post-deploy smoke check fails with a 502 Bad Gateway because the load balancer had no healthy targets yet -- new instances were still registering and passing health checks. The deploy is fine; the check raced target warmup. A human re-runs after warmup and the endpoint returns 200 unchanged.

### How do I fix Self-Healing CI: recovering a load balancer warmup 502 manually?

[object Object]

### Can Self-Healing CI: recovering a load balancer warmup 502 be fixed automatically?

A warmup 502 is distinguishable from a real outage by whether the endpoint recovers once targets become healthy. A self-healing CI pipeline detects the 502-during-warmup condition, waits for healthy targets and re-checks, and only escalates if the endpoint stays unhealthy, which is the real signal of a broken deploy rather than a slow

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt