SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Serverless New Added 26 October 2026

API Gateway: {"message": "Endpoint request timed out"}

API Gateway stopped waiting for the integration, which for REST APIs happens at 29 seconds by default whatever the Lambda function's own timeout says. A function set to five minutes keeps running and finishes successfully in CloudWatch, but its answer is thrown away and the client gets a 504. HTTP APIs stop at 30 seconds. Since 2024 Regional and private REST APIs can raise the integration timeout through a quota request, in exchange for a lower throttle limit.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# How long does the function really take? (Duration in REPORT lines)
aws logs filter-log-events --log-group-name /aws/lambda/my-func --filter-pattern REPORT --max-items 5 --query 'events[].message'

# What is the integration timeout, in milliseconds?
aws apigateway get-integration --rest-api-id abc123 --resource-id xyz789 --http-method POST --query timeoutInMillis

# Best fix: do long work asynchronously. Accept the request, return 202,
# hand the job to SQS or Step Functions and let the client poll for status

# Regional REST API, after the Service Quotas increase is approved
aws apigateway update-integration --rest-api-id abc123 --resource-id xyz789 --http-method POST \
  --patch-operations op=replace,path=/timeoutInMillis,value=60000
aws apigateway create-deployment --rest-api-id abc123 --stage-name prod

How to diagnose Serverless errors

Serverless errors are shaped by hard platform limits: execution duration, deployment package size, memory, and concurrency. Unlike a server you control, these cannot be tuned away. The fix is to restructure the workload. VPC-attached functions add a second class of problem, because they lose default internet access and depend on ENI capacity and NAT configuration.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Check the platform limit before changing code: timeout, package size and memory are all documented, and the error is usually the limit being reported literally.
  2. For timeouts, add timing logs around each external call. A function that times out is nearly always waiting on one downstream dependency.
  3. Reduce package size with layers, tree-shaking, and by excluding dev dependencies and the provider SDK that the runtime already includes.
  4. For VPC functions with no internet access, confirm there is a NAT Gateway or the relevant VPC endpoints. A function in a private subnet cannot reach the public internet by default.
  5. Measure cold start separately from warm invocation in your metrics, and use provisioned concurrency only after confirming cold starts are the actual problem.

Tools worth reaching for

  • CloudWatch Logs Insights
  • aws lambda get-function-configuration
  • X-Ray / distributed tracing
  • sam local invoke

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.aws.amazon.com docs.aws.amazon.com

Related Serverless errors

See all 20 Serverless errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.