ALB Target Group Slow Start: Concurrent Latency Spikes During Target Warm-Up

An Application Load Balancer target group with slow start enabled can exhibit elevated TargetResponseTime only when concurrent requests arrive shortly after targets are registered or transition from unhealthy to healthy. The latency often normalizes after the warm-up window, but CloudWatch metrics alone do not reliably separate the load balancer's intentional request ramp from actual target processing delays.

The core uncertainty is whether this concurrency-only latency reflects the documented slow start behavior—where the load balancer deliberately limits the request share sent to a target during warm-up—or a distinct backend constraint such as connection pool exhaustion or thread saturation that only surfaces under load. Slow start applies to initial target registration and healthy-state transitions, not to bursts against an already warm target group, and its attribute names and defaults can vary by region or console release.

When latency persists beyond the configured duration or appears on targets that have been healthy for an extended period, the root cause may lie outside the load balancer. Without correlating target health timestamps, slow start configuration, and request-level latency distributions, distinguishing between these layers remains difficult.

How can teams determine whether concurrent-only latency is caused by ALB slow start ramp versus backend saturation? What specific signals should be compared to make that distinction? Are there documented behavioral differences between ALB slow start and other load balancer types that affect this diagnosis?