ALB 502 Errors: Find Which Boundary Produced the Response

Classify one ALB 502 using request-bound logs, target evidence and aligned metrics before changing health checks, timeouts or target membership.

Primary sources checked 2026-10-18

An ALB-facing 502 does not identify the failing component. First determine whether the load balancer generated the response or forwarded a valid 502 from a target. Then investigate the connection or HTTP boundary associated with that exact request. A healthy target check and a later successful request do not answer either question.

This guide helps an incident responder and application owner classify existing evidence for an Application Load Balancer forwarding HTTP/1.1 to instance or IP targets over HTTP. It excludes Lambda targets, WebSockets, gRPC, target optimizer, backend TLS and upstream CDN diagnosis. Those paths have additional failure contracts. The outcome is an owned next investigation, not permission to replay production requests, change traffic or widen network access. All examples below are constructed records; no AWS operation or live application test was performed.

Bind one failed attempt to its actual route

Start with the client observation: UTC time, hostname, method, sanitized path, returned status and available correlation identifier. Record whether the client reached this ALB directly or through another proxy. A 502 generated by an upstream proxy belongs to a different boundary even when the same hostname eventually routes to an ALB.

Identify the account, Region, ALB ARN, listener, matching rule, target group and application revision. Preserve the configuration active during the failed attempt separately from the configuration visible now. A request may have matched a nondefault rule; a healthy default target group does not describe every path through the listener.

Use the application's existing correlation scheme where available. Do not invent a one-to-one join by matching only a rounded second or a shared NAT address. If multiple attempts could match, preserve the candidate set and its ambiguity. An operation identifier can be sensitive even when the request body is absent, so retain it only in the approved incident store.

Before any new observation, ask the application owner whether that request can write state or call an external system. A client-visible 502 does not prove the target performed no work. Replaying a payment, invitation or provisioning request can create another effect. This procedure uses retained evidence first and leaves any synthetic request to a separately approved, harmless endpoint.

Read the two status fields together

In the documented ALB access-log format, elb_status_code describes the response status and target_status_code records a status supplied by a responding target. A dash in the latter means that no target response status was recorded under that field's contract. It does not name the reason. AWS access-log field definitions.

For a forward action in this guide's scope, a logged 502 with target status 502 supports a target-generated HTTP error response. The target could itself be a reverse proxy; the application team must continue the trace through that proxy rather than assuming the final business handler emitted the error. A logged 502 with target status dash supports investigating the ALB-to-target response boundary, without distinguishing a reset from malformed headers.

Retain action, chosen target/port, request identity, processing fields and deployment time beside the status pair. A fixed-response listener action is not the same observation as forwarding to a target. Missing or uninterpretable fields make the classification incomplete. Use the schema matching the stored log format, not a hand-counted split that breaks quoted request fields or ignores newly appended columns.

The timing fields are supporting observations. A value of minus one is a sentinel defined by the service, not negative elapsed time. Do not average it into latency or treat a tiny positive duration as proof that a business transaction was rejected before committing. Request and application timelines still need a valid join.

Use metrics to locate the population, not identify the request

HTTPCode_ELB_502_Count counts 502s originating at the load balancer. Target-generated server errors belong to the target 5XX metric family. Use the metric's supported dimensions, period and Sum statistic to align the observation with the affected load balancer and time window. ALB CloudWatch metric definitions.

A dashboard of all target 5XX responses cannot tell you how many were 502 rather than 500 or 503. Likewise, an aggregate ELB 502 spike cannot identify which container reset a connection. Use it to bound the investigation window and compare deployment cohorts, then return to request-level and target evidence.

Keep missing data separate from an observed zero. Verify account, Region, resource dimension, time zone, period and whether the metric reports only nonzero values. A graph with no points is not automatically proof of no failures. Record any dashboard transformation that fills missing values with zero.

Suppose an invented five-minute window contains a metric sum of 17 ELB 502s and 11 target 5XXs. These figures do not establish 28 client 502s. The target family includes other server codes, the dimensions must match, and application-visible retries can change the relationship to business operations. No loss rate or availability percentage can be calculated without a defensible denominator and population contract.

Investigate a mechanism only after the origin is bounded

For ALB-generated 502s, AWS lists several possibilities, including target-side connection resets or closes while a request is outstanding, malformed response headers and response headers exceeding the documented size limit. A deregistration delay ending during an in-flight request is another documented branch. The status alone cannot choose among them. ALB 502 troubleshooting.

Ask the target owner for retained process/reverse-proxy logs around the joined attempt, deployment or shutdown events, connection settings and applicable HTTP response metadata. Existing connection telemetry may support a reset hypothesis. Existing sanitized response-header evidence may support a parser or size hypothesis. An unrelated successful request or a guessed default setting supports neither.

Compare the target's actual keepalive behavior with the ALB idle-timeout setting when the retained evidence points to connection reuse or premature closure. Do not prescribe increasing every timeout. That can retain stalled work longer, move a failure to another client deadline and obscure the original event. AWS distinguishes ALB idle timeout from client keepalive duration; they are different controls. ALB connection attributes.

For target-generated 502s, preserve the target response and follow its upstream dependency evidence. If the target proxy logged an upstream connection failure, the next owner is the proxy/application dependency owner. Changing ALB health settings cannot explain why that valid error response was returned. It may merely route different traffic to the same defect.

Do not use target health as request acceptance

ALB health checks exercise a configured protocol, port and path at intervals. They do not test every production method, payload, authentication path or dependency. A passing lightweight health endpoint can coexist with a failing report-export request. Target-group health-check behavior.

Record the exact check configuration and observation time. A target healthy at 12:10 cannot establish its connection state at 12:03. A probe that returns a permitted success code need not exercise the business condition the incident concerns. Broadening a matcher to include a failing code changes routing admission; it does not repair that condition.

Health-state routing also has exceptions. AWS documents fail-open when all registered targets are unhealthy across the enabled zones. Do not predict that marking every target unhealthy necessarily produces an empty traffic path. An incident change to registration, matcher or zonal treatment requires its own capacity and routing review.

The existing ALB zonal-shift rehearsal owns planned capacity withdrawal and return. The Route 53 health-decision article owns DNS record selection. Neither replaces request-level 502 attribution, and this diagnosis does not authorize either intervention.

Worked scenarios: response origin and replay limits

The following records are synthetic field selections, not literal AWS log lines or observed failures.

A, report request at 12:03:10 UTC

Retained status evidence: Forward action; ELB 502; target status absent; target selected

Supported next investigation: ALB-to-target connection or HTTP response boundary; cause unresolved

B, export request at 12:04:20 UTC

Retained status evidence: Forward action; ELB 502; target 502; matched proxy error record

Supported next investigation: Target proxy's upstream failure; do not classify as ALB-origin solely from client status

C, submit request at 12:05:30 UTC

Retained status evidence: Client 502 only; no unambiguous ALB log or target join

Supported next investigation: Origin unknown; reconcile business effect before any replay

For A, suppose the only additional evidence is a current healthy target and a deploy at 12:02. That narrows a time window but does not establish a shutdown reset. Ask for the process lifecycle and matching request evidence. If the necessary record was never collected, say what a safe isolated observation would need rather than filling in a root cause.

For B, stipulate that the proxy's correlated record identifies an upstream connection refusal. This supports investigation of that upstream path within this constructed example. It does not prove that all 502s in the incident share the cause. Preserve the target, revision and correlation key so another responder can challenge the join.

For C, the application owner finds a committed operation with the original idempotency key. That stipulated business fact changes retry handling even though HTTP origin remains unknown. The next action is to reconcile the existing operation with the caller, not submit it again to obtain a cleaner log. If business state cannot be checked safely, keep the request outcome unresolved and escalate to its owner.

Keep a reusable request-bound worksheet

Use one record per failed attempt or explicitly defined cohort. A field can be unknown; its owner should be named before the incident is handed over.

Client attempt

Record to retain: UTC interval, sanitized method/path, observed status and correlation reference

Routing identity

Record to retain: Account/Region, ALB/listener/rule, target group and applicable revision

Response origin

Record to retain: Action, ELB status, target status, target/port and parser/schema version

Mechanism evidence

Record to retain: Joined target/process/proxy record, connection or header evidence and competing explanation

Metric context

Record to retain: Namespace/name, dimensions, statistic, period, actual points and missing-data treatment

Effect and next owner

Record to retain: Committed/absent/unknown operation, replay restriction, assigned investigation and review time

ALB access logs are best effort, so an absent entry cannot establish that the request never arrived. Preserve collection coverage and any delivery delay when deciding what a missing row means. Avoid turning a sampled worksheet into complete request accounting. The log reference above describes this limitation independently of whether your own parser worked.

For an approved follow-up, use one synthetic operation with an inert downstream path, bounded load/cost and explicit expected observations. Separate the person permitted to collect telemetry from the person permitted to change routing. If a candidate repair changes connection handling, compare fresh and reused connections in that isolated environment instead of silently narrowing the test to the easier cohort.

Failure and recovery boundaries for the next investigation

Waiting for existing logs can preserve the original configuration but may leave an urgent incident unresolved. A separately approved safe synthetic probe can supply new evidence, but it cannot reconstruct the earlier request. A reviewed mitigation may reduce exposure before root cause is known; record that it is a mitigation and keep its reversal conditions separate from diagnosis.

Stop the diagnostic experiment if it reaches a live side effect, unexpected identity, uncontrolled request volume, inaccessible logs or an ambiguous operation outcome. Do not delete targets or replay a batch to improve observability. Reverting a timeout or traffic setting does not undo completed external work. Retain the candidate configuration and comparison evidence even when the attempt fails.

Close this guide's task when another responder can identify the exact request boundary, distinguish observed facts from the remaining hypothesis, and name the smallest permitted next action. Start with one failed attempt and complete the two status fields and action before requesting a change. If those fields are unavailable, assign the evidence gap and business reconciliation first.