Skip to content

The task is running but the ALB marks it unhealthy. What next?

1 min read · main part only; folded sections are optional

After this you can answer: The task is running but the ALB marks it unhealthy. What next?

The target groups expect HTTP 200, check every 15 seconds and allow five seconds per check. The shared configuration requires two successful checks for recovery and three failures for an unhealthy state. Startup grace belongs to the ECS service and must be considered separately from target-group timing.

The API listens for the load balancer on the application port, not the Service Connect proxy port. A process bound only to loopback can pass a container-local check while failing the ALB check. Web task configuration explicitly sets its listening hostname for external reachability.

Do not equate all unhealthy targets with a guaranteed 503. AWS documents fail-open routing when a target group contains only unhealthy registered targets. No targets or unused targets are a different condition. Check registration, health reason and observed response independently. A healthy /health can coexist with failed bookings when Postgres is unavailable.

Would you change /health to require every dependency?
That can remove every task during a shared dependency outage. Choose liveness and readiness behavior intentionally, rather than restarting healthy processes repeatedly.
What if it only fails during deploy?
Inspect startup time, grace period, container checks and service events before widening thresholds. A slower startup and a broken configuration need different fixes.
Can curl from inside the container prove ALB access?
No. It proves a local path. The remote connection also depends on binding, routes, filtering and the registered target address.

Read the path chapter, select the relevant map piece →, then inspect infra/src/entry/target-groups.ts → createTargetGroups. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/