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 (ConvOps 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 (from ConvOps Diagnose's CloudTrail check) to distinguish the two.
Is your UnHealthyHostCount alarm already set up correctly?
The free ConvOps 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 ConvOps 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 ConvOps debugs UnHealthyHostCount alarms
When UnHealthyHostCount triggers an alarm, ConvOps Diagnose reads CloudWatch Logs, CloudTrail (recent API calls, deploys, config changes), and the current resource state in parallel. It correlates these with AWS/ApplicationELB metrics on the same resource — giving you a plain-English root cause with numbered fix options, sent to WhatsApp or Slack, usually within 60 seconds of the alarm firing.
Before any anomaly in UnHealthyHostCount reaches you as a proactive alert (via ConvOps Watch), it passes through 9 verification checks: a Recovery check (did the metric self-heal?), an AWS Status check (is AWS itself having an incident?), a Deploy check (was there a recent Lambda update, ECS deploy, or RDS parameter change in the last 120 minutes?), a Quota check, an Infrastructure check, a Security check, a Flap check (has this metric been anomalous more than 5 times in the last 24 hours?), a TLS check, and a Vulnerability check. Only anomalies that pass all relevant checks reach you — with full context attached.
ConvOps Watch
Detects UnHealthyHostCount anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a UnHealthyHostCount alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
ConvOps 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 (ConvOps 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 (from ConvOps Diagnose's CloudTrail check) 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 ConvOps automatically create CloudWatch alarms for UnHealthyHostCount?+
ConvOps does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free ConvOps Audit scans your CloudWatch setup and tells you which Application Load Balancer resources are missing a UnHealthyHostCount alarm. ConvOps Watch then monitors UnHealthyHostCount using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use ConvOps without already having a UnHealthyHostCount alarm set up?+
Yes. ConvOps Watch monitors UnHealthyHostCount independently of your CloudWatch alarm configuration — it reads the metric directly from CloudWatch every 5 minutes on the Growth plan. If you run the free Audit first, it will tell you which resources need a UnHealthyHostCount alarm and provide the copy-paste AWS CLI command to create it.