# 460 Client Closed Connection (AWS ALB)

> An AWS ALB 460 means the client disconnected before the load balancer idle timeout. Confirm it in access logs, then compare client and target timings.

Source: https://howhttpworks.com/status-codes/460
Last reviewed: 2026-10-05

> **TL;DR:** A 460 in your AWS Application Load Balancer logs means the client hung up before your backend answered, usually because the client's own timeout is shorter than your slow endpoint. Speed up the target or raise the client's timeout. Raising the ALB idle timeout won't help, since the client gave up first.

## What it means

460 is an AWS ALB code, not a standard HTTP status. "Client Closed Connection" is a descriptive label here; [AWS documents the numeric code](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-errors) without a reason phrase. You'll only ever see it in logs: the client has already disconnected, so no response with this code reaches it.

First figure out who is directly in front of the ALB. If it's another proxy, its timeout matters as much as the end user's. Sketch the real request path before you touch any timeouts.

## Confirm it in access logs

Filter ALB access logs on `elb_status_code = 460`. That field is the load balancer's status. `target_status_code` holds the target's response code, or `-` when no target response was recorded. Even with a `-` there, the application may have started the work, or even finished it. See [AWS's field definitions](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html).

Match the timestamp, URL, and client against the caller's logs. Note when the caller started, when it cancelled, and when the target finished. Then check the ALB's configured idle timeout with this read-only AWS CLI call, after setting `ALB_ARN` to your load balancer's ARN:

```bash
aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn "$ALB_ARN" \
  --query "Attributes[?Key=='idle_timeout.timeout_seconds']"
```

The [default is 60 seconds](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#load-balancer-attributes), but compare against whatever your deployment actually uses.

## Fix it

If the cancellations line up with the client's configured timeout, you have two options: make the target finish sooner, or raise that client timeout if the caller can afford to wait. AWS specifically recommends checking the client timeout against the ALB idle timeout. After the change, retest the slow endpoint with the same caller.

If the caller cancelled on purpose, such as a user navigating away or a script aborting, find out why before you change any configuration. For requests that modify state, check whether the operation went through before retrying. The client disconnecting doesn't roll anything back on the server.

## Do not confuse it with an ALB idle timeout

When the target doesn't respond before the ALB idle timeout, AWS logs a [504](https://howhttpworks.com/status-codes/504) instead. That's a different investigation from a 460. The question is who stopped waiting first: the client (460) or the ALB (504). The access log tells you which.

## Related

- [499 Client Closed Request](https://howhttpworks.com/status-codes/499)
- [408 Request Timeout](https://howhttpworks.com/status-codes/408)
- [504 Gateway Timeout](https://howhttpworks.com/status-codes/504)