## TL;DR

Your targets are up but return 502 on the health check path, which usually means the app crashes or errors on that specific path, or a proxy in front of the app is misconfigured. Hit the health check path directly on the target, bypassing the ALB, and fix whatever returns 502 there. Then confirm the target group's health check path, port, and protocol match what the app actually serves.

```text
AWS ALB "Health checks failed with these codes: [502]": target debugging
```

## Steps

1. Open the target group and note the health check protocol, port, and path.
Expected: You know exactly what the ALB is requesting.

2. Request that same path directly on a target instance, bypassing the ALB.
Expected: You reproduce the 502 without the ALB in the path, proving the target is the source.

3. Fix the underlying cause: a crashing handler on the health path, a proxy returning 502, or the app not listening on the checked port.
Expected: The direct request to the health path returns 2xx.

4. Wait for the next health check interval and confirm the targets flip to healthy.
Expected: The target group shows healthy targets.

## Use this when

- The ALB target group reports health checks failed with code 502.

- Targets register fine but never become healthy.

- A deploy changed the health endpoint or the app's listening port.

## Not for this skill when

- 502s returned to real client traffic through ALB listeners (different fix).

- Targets failing to register at all or connection-level health check failures.

- Health checks failing with 500, 503, or timeout rather than 502.

## Variant phrasings

### ALB target health check 502

### ALB targets unhealthy 502

### ALB health check failed code 502

## Why it happens

The ALB marks a target unhealthy when its health check gets a non-2xx code. A 502 on the check path means something between the ALB and the app - or the app's handler for that path - failed, while the target itself is reachable enough to get a response.

## Edge cases

- Security groups must allow the ALB's health check traffic to the target port - blocked checks look different but verify anyway.

- An app listening only on the loopback interface is unreachable to the ALB even though local curl works.

- Health paths that require authentication return errors; use a dedicated unauthenticated health endpoint.

- Slow-start and deregistration delay settings can keep fresh targets out of rotation longer than expected.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i9i2DXLrGsErZFvbn9p7DQ