ELB 5xx Errors

Overview

Overview

When an ALB returns 5xx errors, the cause is either the ALB itself (502, 503) or the backend targets (504, or a 502 when the backend sends an invalid response). Knowing what each code means tells you where to look.

What each code means

• 502 Bad Gateway — The ALB connected to a target but got an invalid response: not valid HTTP, a reset (RST) or incomplete — Backend closed the connection before a complete response (crash, OOM kill mid-request); a response the ALB cannot parse; backend Keep-Alive timeout shorter than the ALB's
• 503 Service Unavailable — The ALB has no healthy targets; all fail health checks — Application not started, health check path returning non-200, deployment in progress, security group blocking health checks from the ALB
• 504 Gateway Timeout — The backend did not respond within the timeout (default 60 seconds for ALB) — Slow database query, external API call with no timeout, slow CPU-bound operation, GC pause

> [!TIP] For a 503, check target health in the ALB Target Groups console first.

ALB access log fields

ALB access logs are the authoritative source.

• Request processing time — Time from request received to response started
• Backend processing time — How long the backend took to respond; -1 means it did not respond at all
• Target status code — The backend's response
• ELB status code — What the client received

Key concepts

HTTP 502 (Bad Gateway)

ALB got a response from the target but it was invalid or the connection was reset. Often an application crash mid-response or Keep-Alive timeout mismatch.

HTTP 503 (Service Unavailable)

ALB has no healthy targets. Check target group health. Security group blocking health check, wrong health check path, or deployment in progress.

HTTP 504 (Gateway Timeout)

Backend is alive but did not respond within the idle timeout (default 60s). The backend is slow — check for slow queries, external timeouts, or GC pauses.

ALB access logs

Per-request logs including request_processing_time, target_processing_time, response_processing_time, target_status_code. Enable in ALB Attributes. Stored in S3. Query with Athena.

Target health check

ALB sends periodic HTTP requests to target health check path (default /). Expects 200 (or configured 2xx/3xx range). Unhealthy threshold: 2 consecutive failures.

When to use it

• Diagnosing whether a 502 came from the ALB or the backend application
• Determining why all targets in an ALB target group show as unhealthy
• Tuning ALB timeout settings for slow downstream dependencies
• Reading ALB access logs to find the exact backend processing times

Interview questions

• Users are seeing 502 errors from your ALB. How do you find the root cause?

More Troubleshooting topics

• Database Migrations in Production
• Deployment Rollback Strategies
• Disk IOPS Saturation
• DNS Failures
• EC2 Instance Unresponsive
• ECS Task Failures and Restarts
• Flaky CI/CD Pipeline Failures
• HPA Not Scaling
• IAM Permission Denied Errors
• JVM Garbage Collection Pauses
• Kubernetes Service Not Reachable
• Lambda Cold Start Latency