Fix AWS Error 504 Gateway Timeout On Application Load Balancer (2025)

Updated: 11/29/2025

You deploy a new service behind an AWS Application Load Balancer or API Gateway, send what looks like a simple HTTP request, and instead of a JSON response you get a blank page with 504 Gateway Timeout. It can be frustrating because the application might work when you curl the instance directly but fail as soon as traffic comes through the AWS managed endpoint. A 504 almost always means the load balancer or gateway waited for your target long enough then gave up without receiving a complete response.

The key is to treat Error 504 not as a single bug but as a symptom of delays anywhere in the path, from DNS and security groups to the web server and database. By testing connectivity from inside your VPC, checking health checks, and tuning idle timeout values you can usually identify which hop is too slow and restore a stable low latency path for users.

Table of Contents

Method 1: Confirm Target Health And Security Groups

In many AWS environments 504 Gateway Timeout occurs when the Application Load Balancer is trying to route to a target that is technically up but cannot accept traffic due to incorrect security group rules or failing health checks. Fixing these networking basics usually clears the error before you need to touch application code.

Step 1: Check Target Group Health In The Console

Log in to the AWS Management Console then go to EC2 > Target Groups and select the target group associated with your load balancer listener. Open the Targets tab and verify that each instance or IP shows as healthy if you see unhealthy statuses click an individual target to inspect the last health check code and response time.

Step 2: Review Security Group Rules

From the same EC2 section open the security group attached to your application instances, make sure the inbound rules allow the load balancer security group on the correct listener port such as 80 or 443 and verify that no overly strict network ACL is blocking the traffic. Remember that the load balancer connects using its own security group not the public internet directly.

Step 3: Test Connectivity From Inside The VPC

Use an EC2 bastion host in the same VPC or the AWS Systems Manager Session Manager to start a shell on an instance that can reach your targets, then send a test request to the application port to verify local health for example

curl -v http://your-target-private-ip-or-hostname:80/health

If this local test is slow or fails the issue is with the instance itself or its local firewall not with the load balancer.

Method 2: Tune Idle Timeouts And Application Response Time

Sometimes your service is doing expensive work or waiting on a slow downstream dependency like a database or external API. If that work takes longer than the Application Load Balancer or API Gateway idle timeout you will see periodic 504 Gateway Timeout responses even though the target eventually finishes the job. Aligning your service time and infrastructure timeouts is critical for long running requests.

Step 1: Check Current Idle Timeout On The Load Balancer

In the AWS Console go to EC2 > Load Balancers choose your Application Load Balancer then open the Attributes tab. Look for the Idle timeout value which by default is often 60 seconds, if your typical request can legitimately take longer you may need to increase this value cautiously.

Step 2: Measure Real Application Latency

On one of your target instances tail the application logs and time a known slow endpoint using curl or a similar tool, for example

time curl -v http://localhost:8080/slow-endpoint

Compare this actual response time to the load balancer idle timeout, if the application regularly exceeds it you either need to optimize the code or accept a higher timeout for that path.

Warning: Increasing idle timeouts very high can hide performance problems and tie up load balancer connections under traffic spikes, always combine timeout changes with profiling and caching where possible.

Method 3: Debug API Gateway And Lambda 504 Errors

If your 504 appears when calling an Amazon API Gateway endpoint backed by AWS Lambda the cause is usually either a Lambda timeout shorter than the work being done or an integration timeout at the gateway level. You need to verify both the Lambda configuration and the API Gateway stage settings to find which limit is ending the connection first.

Step 1: Inspect Lambda Timeout Setting

Open the Lambda section of the AWS Console select your function then open the Configuration tab and find the General configuration area. Check the Timeout setting, if your handler might take longer for large payloads or cold starts consider increasing it slightly while you work on code efficiency.

Step 2: Review API Gateway Integration Timeout

In the API Gateway console choose your API and stage then open the integration request or route settings depending on whether you use the REST or HTTP API type. Confirm that the integration timeout is not lower than your Lambda timeout, if it is the gateway will terminate the request early and return a 504 even though Lambda is still working.

Step 3: Enable Detailed Logging For Troubleshooting

Enable execution logs to CloudWatch for both API Gateway and the Lambda function, then reproduce the failing request and check the timestamp where the 504 appears. Use that timeline to correlate which component returned an error or stopped sending data so you can target your fix precisely instead of guessing.