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 (ConvOps 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 ConvOps 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 ConvOps 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 ConvOps debugs HTTPCode_ELB_5XX_Count alarms
When HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a HTTPCode_ELB_5XX_Count 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 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 (ConvOps 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 ConvOps automatically create CloudWatch alarms for HTTPCode_ELB_5XX_Count?+
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 HTTPCode_ELB_5XX_Count alarm. ConvOps Watch then monitors HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count alarm set up?+
Yes. ConvOps Watch monitors HTTPCode_ELB_5XX_Count 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 HTTPCode_ELB_5XX_Count alarm and provide the copy-paste AWS CLI command to create it.