CloudWatch Metric Guide
HTTPCode_ELB_5XX_CountApplication Load Balancer CloudWatch metric
HTTPCode_ELB_5XX_Count counts HTTP 5XX response codes generated by the load balancer itself — not by the registered targets. These indicate the ALB could not deliver the request to a healthy target.
What it measures
About HTTPCode_ELB_5XX_Count
HTTPCode_ELB_5XX_Count counts HTTP 5XX response codes generated by the load balancer itself — not by the registered targets. These indicate the ALB could not deliver the request to a healthy target.
| Namespace | AWS/ApplicationELB |
| Metric name | HTTPCode_ELB_5XX_Count |
| Unit | Count |
| AWS docs | Official Application Load Balancer metrics reference |
Why this metric matters
There is a critical distinction between ALB 5xx errors and target 5xx errors. HTTPCode_Target_5XX_Count measures errors that came from your backend. HTTPCode_ELB_5XX_Count measures errors where the ALB couldn't even reach a healthy backend — this is a harder failure.
When this metric is non-zero, it usually means all registered targets in a target group are unhealthy, the ALB ran out of connections to send to targets, or the request timed out waiting for a target response. From the user's perspective, they get a 502 or 503 with no application logic involved. These events are always worth investigating — they represent requests that completely failed to reach your application.
Recommended alarm threshold for HTTPCode_ELB_5XX_Count
Recommended threshold
> 0 in any 5-minute window
HTTPCode_ELB_5XX_Count represents requests that the load balancer could not serve — these are complete failures, not degraded responses (Nuberio recommendation). Zero tolerance is correct for production. Even a single ELB 5xx during off-peak hours is worth investigating, as it typically indicates an infrastructure problem that will worsen under load.
Is your HTTPCode_ELB_5XX_Count alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including HTTPCode_ELB_5XX_Count — in 5 minutes.
Common failures that show up in HTTPCode_ELB_5XX_Count
When HTTPCode_ELB_5XX_Count reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
All targets unhealthy — a bad deploy causes all backend instances to fail health checks simultaneously, leaving the ALB with no targets to route to
Target group deregistration race — during a rolling deploy, too many targets are deregistered before replacements are healthy
Connection timeout — the ALB idle timeout (default 60 seconds per AWS documentation) is exceeded while waiting for a slow target response
Surge queue overflow — the load balancer's surge queue fills up during traffic spikes, causing it to return 503 to new requests
SSL/TLS handshake failure — the ALB cannot complete the SSL handshake with a target that uses HTTPS health checks with an expired certificate
How the Nuberio Audit checks HTTPCode_ELB_5XX_Count
The free Audit scans every Application Load Balancer resource in your account and checks whether a HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count alarms. Free, 5-minute read-only scan.
Related Application Load Balancer metrics
HTTPCode_ELB_5XX_Count rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Application Load Balancer coverage.
FAQ
Frequently asked questions about HTTPCode_ELB_5XX_Count
Common questions about setting up CloudWatch alarms for HTTPCode_ELB_5XX_Count in Application Load Balancer.
What is the recommended CloudWatch alarm threshold for HTTPCode_ELB_5XX_Count?+
> 0 in any 5-minute window. HTTPCode_ELB_5XX_Count represents requests that the load balancer could not serve — these are complete failures, not degraded responses (Nuberio recommendation). Zero tolerance is correct for production. Even a single ELB 5xx during off-peak hours is worth investigating, as it typically indicates an infrastructure problem that will worsen under load.
Which CloudWatch namespace does HTTPCode_ELB_5XX_Count belong to?+
HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count?+
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 HTTPCode_ELB_5XX_Count alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a HTTPCode_ELB_5XX_Count alarm set up?+
Yes. The free Audit works whether or not you have any HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.