The Scenario
It’s 3:00 PM on a Tuesday, and you just pushed a new version of your order-processing Lambda. The CI/CD pipeline passes, but five minutes later, PagerDuty lights up. Your API endpoint is returning 504s, and CloudWatch logs are full of Task timed out after 3.00 seconds. You check the function’s configured timeout—it’s 3 seconds. Classic.
Symptoms
- CloudWatch logs show
Task timed out after <duration>at the end of each invocation. - API Gateway returns
504 - Endpoint request timed out. - The Lambda function never reaches the final
returnstatement in your code.
Root Cause
Your Lambda function is exceeding its configured Timeout value (default 3 seconds, max 15 minutes). This happens when the function’s execution time—including cold starts, network calls (e.g., to a database or external API), and CPU-bound work—surpasses the limit. The Lambda service kills the execution context and returns the error. Common culprits: a slow downstream service, an unoptimized database query, or a VPC configuration that adds a 2-second cold start latency.
Resolution (Step-by-Step)
-
Increase the timeout
If the task is genuinely long-running, bump the timeout. Use the AWS CLI or console.aws lambda update-function-configuration --function-name my-function --timeout 30Max is 900 seconds (15 minutes). For API Gateway-backed Lambdas, keep it under 29 seconds to avoid API Gateway’s own timeout.
-
Check VPC configuration
If your Lambda is in a VPC, it needs a NAT Gateway or VPC Endpoint for internet access. Without one, network calls hang until timeout.# Check VPC config aws lambda get-function-configuration --function-name my-function | jq '.VpcConfig'Ensure the subnet has a route to a NAT Gateway or use VPC Endpoints for services like DynamoDB or S3.
-
Optimize the code
Profile your function locally. Look for blocking I/O, unoptimized loops, or unnecessary retries. Use async/await in Node.js or asyncio in Python to avoid blocking the event loop. -
Increase memory
More memory also allocates more CPU, speeding up execution. This can reduce runtime for compute-heavy tasks.aws lambda update-function-configuration --function-name my-function --memory-size 1024 -
Debug with tracing
Enable AWS X-Ray to pinpoint the slow segment.aws lambda update-function-configuration --function-name my-function --tracing-config Mode=ActiveThen check the X-Ray traces in the console.
Why This Sometimes Doesn’t Work
Increasing the timeout is a band-aid. If the underlying issue is a deadlock in a database connection pool or an infinite loop, the function will keep timing out at the new limit. Always profile first. Also, Lambda’s 15-minute hard cap means you can’t fix genuinely long-running tasks this way—you need to refactor to Step Functions or ECS. Another gotcha: VPC cold starts can add 5-10 seconds for ENI attachment; increasing timeout alone won’t fix the user experience if your function is latency-sensitive.
Verification
Check CloudWatch logs for REPORT lines. Look for Duration:—it must be less than the new timeout.
aws logs filter-log-events --log-group-name /aws/lambda/my-function --filter-pattern "REPORT" --limit 5
Expected output snippet:
REPORT RequestId: ... Duration: 2500.00 ms Billed Duration: 2501 ms Memory Size: 1024 MB Max Memory Used: 512 MB
If Duration is consistently close to the timeout, you still have a problem.
Common Follow-up Questions
Q: Why does my Lambda timeout only on the first invocation?
A: That’s a cold start. If you’re in a VPC, the ENI attachment adds 2-5 seconds. Increase timeout to 10 seconds or use Provisioned Concurrency.
Q: Can I set timeout to 900 seconds for an API Gateway endpoint?
A: No. API Gateway has a 29-second hard limit for integration responses. Use ALB or direct Lambda invocation for longer tasks.
Q: Will increasing memory always reduce execution time?
A: Only for CPU-bound tasks. If you’re waiting on an external API, more memory won’t help—you need to optimize the network call or add caching.
Prevent This in the Future
Monitor Lambda duration and timeout errors proactively with a tool like Better Stack. Set up alerts when average duration exceeds 80% of your configured timeout, and track cold start rates to catch regressions before they cause outages.
Set up uptime monitoring and alerts with Better Stack