Mastering AWS ALB Access Logs: Debugging Latency, 5xx Errors, and Traffic Spikes
A practical guide to parsing AWS Application Load Balancer access logs, isolating target response latency, and diagnosing high-concurrency production issues.
Written from direct production experience debugging ALB 5xx spikes and tail-latency incidents at scale.
AWS Application Load Balancer (ALB) access logs provide detailed record-level insight into every HTTP request routed through your infrastructure. This guide breaks down the raw log format, timing fields, status codes, and methods to isolate target application latency from network bottlenecks.
1. Structure & Anatomy of an AWS ALB Access Log Entry
AWS ALB access logs are space-delimited text records delivered to Amazon S3 as gzipped files every 5 minutes. Each line represents a single HTTP request processed by the load balancer.
Here is an annotated example of a standard HTTP/2 log line:
https 2026-07-20T14:32:10.123456Z app/prod-alb/50dc6c495c0c9188 192.0.2.45:54312 10.0.1.99:8080 0.002 0.145 0.001 200 200 354 4812 "GET https://api.example.com:443/v1/orders?status=active HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/prod-api/73e2d6bc24d8a067 "app/prod-alb/50dc6c495c0c9188" "Matched" "2026-07-20T14:32:09.975000Z" "forward" "-" "-" "10.0.1.99:8080" "200" "-" "-"Key Timing Fields to Know
Understanding the three core time durations is crucial when determining whether latency stems from the client, the load balancer, or backend application servers:
- `request_processing_time` (0.002s): Time elapsed from when the ALB receives the request from the client until it sends the request to a backend target. High values indicate ALB overload or connection setup friction.
- `target_processing_time` (0.145s): Time elapsed from when the ALB sends the request to the target backend until the target starts sending response headers back. This is your backend application execution time.
- `response_processing_time` (0.001s): Time elapsed from when the ALB receives the response header from the target until it finishes sending the response to the client. High values usually indicate client slow downloads or network congestion.
2. Diagnosing Backend Latency vs Network Bottlenecks
When users report slow page loads or API timeouts, inspecting aggregate HTTP timing metrics tells you exactly where time was spent.
The Special Meaning of `-1` Timings
In ALB logs, a timing value of -1 means the phase could not be completed:
- `target_processing_time = -1`: The load balancer could not route the request to any healthy backend target. This occurs during target group connection timeouts, HTTP 502 Bad Gateway responses, or when backend containers crash during connection acceptance.
- `request_processing_time = -1`: The client disconnected or aborted the TLS handshake before the request headers could be fully received.
Latency Percentiles: Why Averages Lie
Analyzing average response times across thousands of requests hides micro-bursts and tail latency. You should compute P50 (Median), P95, and P99 response times for your target endpoints:
- P50: The baseline user experience. 50% of requests are faster than this threshold.
- P95: Indicates tail latency for 5% of your slowest users (e.g. cold starts, un-cached queries).
- P99: Highlights severe edge cases, database lock contention, or garbage collection pauses.
3. Troubleshooting 502 Bad Gateway and 504 Gateway Timeouts
Distinguishing between 5xx errors generated by the ALB vs 5xx errors generated by your backend container is straightforward when reviewing the dual HTTP status code fields in ALB logs:
... [elb_status_code] [target_status_code] ...| elb_status_code | target_status_code | Root Cause | Common Drivers |
|---|---|---|---|
| 502 | - | ALB received an invalid response or unexpected TCP RESET from the backend before headers were delivered | Backend process crash, OOM killer, or Keep-Alive timeout misconfiguration where the target closes connections faster than the ALB's idle timeout |
| 504 | - | The target failed to respond within the configured ALB Target Timeout (default: 60 seconds) | Un-indexed SQL query execution, a synchronous external API call hanging, or worker pool starvation |
| 500 | 500 | The backend application returned an explicit HTTP 500 — the ALB successfully proxied the response | Unhandled exception in application code; check CloudWatch / Sentry logs directly |
4. Fast Local Log Analysis without CloudWatch Insights Overhead
While Amazon Athena and CloudWatch Log Insights are powerful for multi-gigabyte queries, running ad-hoc log analysis on a production issue often requires rapid, zero-overhead tools.
Using browser-based Web Workers, you can parse tens of thousands of log lines entirely on your local machine without uploading sensitive client IPs or payload metadata to external servers.
Try our free [AWS ALB Log Parser](/tools/aws/aws-alb-log-parser) tool to upload raw .log or .gz ALB files and instantly generate:
- Target response time percentiles (P50 / P95 / P99).
- Status code breakdown (2xx, 3xx, 4xx, 5xx).
- Slowest API endpoints sorted by P95 latency.
- Total request volume per minute.
Frequently Asked Questions
What is the difference between request_processing_time and target_processing_time in ALB logs?
request_processing_time measures how long the ALB itself takes to receive the client request before forwarding it to a target. target_processing_time measures how long your backend application takes to process the request and start sending a response — it is the field that reflects your own application's execution time.
What does target_processing_time = -1 mean in ALB access logs?
A value of -1 means the ALB could not complete that phase at all — most commonly because it could not route the request to any healthy backend target, due to a target-group connection timeout, an HTTP 502 response, or a backend container crashing during connection acceptance.
Why do ALB logs show elb_status_code and target_status_code as different values?
The ALB and the backend target can each independently generate a status code. When the target never responds (a crash or timeout), the ALB emits its own 502/504 while target_status_code shows a dash (-). When both fields show the same code, the ALB successfully proxied the target's own response.
How often does AWS deliver ALB access logs to S3?
AWS delivers ALB access logs to the configured S3 bucket as gzip-compressed files on a rolling basis, typically every 5 minutes, once access logging is enabled on the load balancer.