Introduction

An AWS Application Load Balancer target group becomes unhealthy when the load balancer cannot complete its configured health checks against your registered targets. The problem is usually caused by a mismatch between the health check configuration and the service that is actually listening, or by network rules that block probe traffic before it reaches the application.

Symptoms

  • The ALB target group shows one or more targets as unhealthy in the AWS console.
  • Users receive 502, 503, or intermittent backend connection errors through the ALB.
  • New deployments succeed, but traffic never shifts to the updated targets.
  • ALB health check status descriptions mention timeout, failed response codes, or connection errors.
  • Direct access to the instance or container may work while traffic through the ALB fails.

Common Causes

  • The health check path returns a redirect, authentication challenge, or non-200 response.
  • The target group health check port does not match the port your app actually listens on.
  • Instance, node, or task security groups do not allow inbound traffic from the ALB security group.
  • Network ACLs, host firewall rules, or container networking block the probe.
  • The application is slow to start and fails before the healthy threshold is reached.
  • The registered target type is wrong for the workload, such as instance versus IP targets.

Step-by-Step Fix

  1. Open the target group and review the exact health check failure reason for each unhealthy target. Note the protocol, port, path, timeout, interval, and success code range.
  2. Test the health endpoint directly from inside the same network path. Confirm that the configured path responds quickly and returns a success status code without requiring login, cookies, or special headers.
  3. Verify that the service is listening on the same port defined in the target group. If the application moved to a different container port or process port, update the target group or the workload configuration so they match.
  4. Check security groups carefully. The target must allow inbound health check traffic from the ALB security group on the health check port. If the app runs in ECS, EKS, or on EC2, verify both workload and node-level security rules.
  5. Review network ACLs and any host-based firewall rules. Make sure they do not block the ALB subnets or the health check port.
  6. Confirm that the health check path is stable. Replace complex paths with a lightweight readiness endpoint that verifies only the dependencies required to serve traffic.
  7. If the service is slow to boot, adjust the healthy threshold, timeout, or deployment grace period so new targets are not marked unhealthy before initialization completes.
  8. Re-check listener rules and target registration. Make sure the correct target group is attached to the listener and that the expected instances, pods, or task IPs are registered.
  9. After applying the fix, wait for the required number of successful checks and confirm the target state changes to healthy.
  10. Validate end-user traffic through the ALB, not just direct backend access, and watch CloudWatch metrics for renewed 5xx spikes.