CloudWatch Metric Guide
UnHealthyHostCountApplication Load Balancer CloudWatch metric
UnHealthyHostCount reports the number of targets (EC2 instances, ECS tasks, Lambda functions) registered with the ALB target group that are currently failing health checks.
What it measures
About UnHealthyHostCount
UnHealthyHostCount reports the number of targets (EC2 instances, ECS tasks, Lambda functions) registered with the ALB target group that are currently failing health checks.
| Namespace | AWS/ApplicationELB |
| Metric name | UnHealthyHostCount |
| Unit | Count |
| AWS docs | Official Application Load Balancer metrics reference |
Why this metric matters
UnHealthyHostCount is a direct capacity readout. If you have 4 targets and 2 are unhealthy, you're serving production traffic at 50% capacity. The 2 healthy targets are receiving twice their intended load — making them the most likely candidates to become unhealthy next.
The failure cascade is the key risk: the first unhealthy target increases load on remaining healthy targets, potentially pushing them toward health check failure, which removes them from rotation, which further increases load on the remaining targets. This positive feedback loop can take a partial outage to a full outage in minutes. Catching UnHealthyHostCount at the first non-zero value is what prevents the cascade.
Recommended alarm threshold for UnHealthyHostCount
Recommended threshold
> 0 (any unhealthy host in a production target group)
Any unhealthy target in production means the service is operating at reduced capacity (Nuberio recommendation). The appropriate response depends on context — a rolling deploy will briefly show unhealthy hosts, while persistent UnHealthyHostCount indicates a genuine failure. Combine this alarm with deployment metadata (e.g. a CloudTrail-based deploy timeline) to distinguish the two.
Is your UnHealthyHostCount alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including UnHealthyHostCount — in 5 minutes.
Common failures that show up in UnHealthyHostCount
When UnHealthyHostCount reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Health check endpoint returning non-2xx — a code change breaks the /health route, causing all new or replaced instances to fail health checks immediately after deployment
Application startup too slow — the health check starts before the application is ready, and the grace period isn't long enough for slow-starting services
Port misconfiguration — health check port doesn't match the port the application is actually listening on after a configuration change
Memory pressure causing slow health check response — an overloaded instance responds to health checks slowly, eventually timing out and being marked unhealthy
Security group rule blocking health check traffic — a firewall change blocks the ALB's IP range from reaching the health check port on instances
How the Nuberio Audit checks UnHealthyHostCount
The free Audit scans every Application Load Balancer resource in your account and checks whether a UnHealthyHostCount alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured UnHealthyHostCount alarms. Free, 5-minute read-only scan.
Related Application Load Balancer metrics
UnHealthyHostCount rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Application Load Balancer coverage.
FAQ
Frequently asked questions about UnHealthyHostCount
Common questions about setting up CloudWatch alarms for UnHealthyHostCount in Application Load Balancer.
What is the recommended CloudWatch alarm threshold for UnHealthyHostCount?+
> 0 (any unhealthy host in a production target group). Any unhealthy target in production means the service is operating at reduced capacity (Nuberio recommendation). The appropriate response depends on context — a rolling deploy will briefly show unhealthy hosts, while persistent UnHealthyHostCount indicates a genuine failure. Combine this alarm with deployment metadata (e.g. a CloudTrail-based deploy timeline) to distinguish the two.
Which CloudWatch namespace does UnHealthyHostCount belong to?+
UnHealthyHostCount is published in the AWS/ApplicationELB namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/ApplicationELB". See the Application Load Balancer CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for UnHealthyHostCount?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Application Load Balancer resources are missing a UnHealthyHostCount alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a UnHealthyHostCount alarm set up?+
Yes. The free Audit works whether or not you have any UnHealthyHostCount alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which Application Load Balancer alarms your account is missing — including UnHealthyHostCount — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.