AWS Lambda: Task timed out after X seconds — function execution exceeded timeout
Task timed out — Lambda exceeded execution limit
Verified against AWS Lambda docs: Configuring function timeout, AWS Lambda runtime lifecycle documentation, AWS re:Invent 2024: Lambda performance optimization best practices · Updated June 2026
> quick_fix
Your Lambda function ran longer than its configured timeout (default: 3 seconds, max: 900 seconds). Either increase the timeout in the function configuration, or optimize the function to run faster — common culprits are cold starts, slow external API calls, and unoptimized database queries.
# Check current timeout:
aws lambda get-function-configuration \
--function-name my-function \
--query 'Timeout'
# Increase timeout (e.g., to 30 seconds):
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30What causes this error
Lambda enforces a hard timeout on every invocation. When the function's execution time exceeds this limit, the Lambda runtime kills the process and returns a 'Task timed out' error. The default timeout is 3 seconds — too short for most real-world functions that make API calls, query databases, or process files. The timeout is a safety mechanism: without it, a stuck function would consume compute indefinitely. But the default is aggressively low, and Lambda doesn't warn you that you're approaching the limit — it just kills the function at the exact boundary.
How to fix it
- 01
step 1
Check the current timeout setting
In the Lambda console or CLI, check what the timeout is set to. If it's the default 3 seconds, that's almost certainly too low for any function making external calls.
aws lambda get-function-configuration \ --function-name my-function \ --query '{Timeout: Timeout, MemorySize: MemorySize}' - 02
step 2
Increase the timeout to a reasonable value
Set the timeout to cover your function's expected execution time plus a margin. For API-calling functions, 30-60 seconds is common. For file processing, you may need 300+ seconds. Maximum is 900 seconds (15 minutes).
aws lambda update-function-configuration \ --function-name my-function \ --timeout 60 - 03
step 3
Check if cold starts are the bottleneck
The first invocation after idle time includes initialization (loading runtime, dependencies, connecting to databases). In Node.js/Python this adds 0.5-2s; in Java/C# it can add 5-10s. Check CloudWatch Logs for 'Init Duration' — if it's significant, consider Provisioned Concurrency.
# Check recent invocation durations: aws logs filter-log-events \ --log-group-name /aws/lambda/my-function \ --filter-pattern 'Duration' \ --limit 10 - 04
step 4
Profile external call latency
If the function calls external APIs, databases, or S3, add timing logs around each call. The timeout often isn't the function's code being slow — it's waiting on a downstream service that's responding slowly or timing out itself.
- 05
step 5
Increase memory to get more CPU
Lambda allocates CPU proportionally to memory. A function with 128MB gets 1/8th of a vCPU; 1769MB gets a full vCPU. If your function is CPU-bound (JSON parsing, image processing), increasing memory can reduce execution time enough to fit within the timeout.
How to verify the fix
- Lambda invocations complete without 'Task timed out' errors.
- CloudWatch Logs show 'Duration' consistently below the timeout setting.
- The function returns the expected response within the timeout.
Why Task timed out happens at the runtime level
Lambda's execution environment runs your function handler inside a sandbox. The runtime API (lambda/runtime/init) starts a deadline timer when the invocation begins. This timer is managed by the Lambda service, not the runtime — your code can't catch or extend it. When the deadline fires, the service sends SIGTERM to the process, waits briefly, then sends SIGKILL. The 'Task timed out' message is logged by the Lambda service itself (not your code) and returned as an error to the caller (API Gateway returns 502, async invocations go to the DLQ). The function's execution context is frozen (not destroyed) after timeout — on the next invocation, the same container may be reused with stale state from the timed-out execution.
Common debug mistakes for Task timed out
- Setting the timeout to exactly the expected execution time with no margin — network latency, cold starts, and downstream slowdowns can push execution 2-3x longer than average. Set timeout to 3-5x the median execution time.
- Increasing timeout to 900 seconds without investigating why the function is slow — a 15-minute Lambda is usually a sign the workload should be on ECS/Fargate or broken into Step Functions steps.
- Not increasing API Gateway timeout when increasing Lambda timeout — API Gateway has its own 29-second hard limit. A Lambda behind API Gateway can never run longer than 29 seconds regardless of Lambda's own timeout setting.
- Ignoring cold start impact on Java/.NET Lambda functions — JVM and CLR startup adds 5-15 seconds. If timeout is 10 seconds, cold starts will timeout every time. Use Provisioned Concurrency or switch to a lighter runtime.
- Not checking Lambda memory allocation — Lambda allocates CPU linearly with memory. A 128MB function gets minimal CPU. Doubling memory to 256MB can halve execution time for CPU-bound work.
When Task timed out signals a deeper problem
Frequent Lambda timeouts across multiple functions usually indicate a missing observability layer. Without distributed tracing (X-Ray, Datadog APM), you can't see that the Lambda itself takes 200ms but spends 28 seconds waiting for a VPC-peered RDS instance to respond to a query that's doing a full table scan. The architectural fix is: (1) add X-Ray tracing to see exactly where time is spent, (2) move database connections to RDS Proxy to eliminate cold-start connection overhead, and (3) set up CloudWatch alarms on p99 duration so you catch timeout trends before they become outages.
Editor's take
The Lambda timeout that taught me the most was a function that worked perfectly for 6 months and then started timing out every Monday morning. The cause: the function connected to an RDS PostgreSQL instance inside a VPC. Over the weekend, the RDS instance's connection pool would fill up with idle connections from other services. Monday morning, the Lambda's cold start would try to establish a new connection, get queued behind 200 idle connections waiting to be reaped, and time out at the 3-second default. The fix was RDS Proxy, which took 10 minutes to set up and eliminated the problem entirely.
The key insight about Lambda timeouts is that the timeout includes everything: cold start initialization, handler execution, and waiting on external calls. A function that runs in 2 seconds with a warm container might take 12 seconds on cold start (10s JVM init + 2s execution). If your timeout is 10 seconds, cold invocations will timeout while warm ones succeed — creating the confusing pattern of 'works most of the time but fails randomly'.
Adjacent errors you'll encounter: 'Runtime exited with error: signal: killed' (Lambda killed the process after timeout), 'Connection timed out' from the SDK when calling another AWS service inside the Lambda (the downstream call exceeded its own timeout), and API Gateway's '504 Gateway Timeout' when the Lambda runs longer than API Gateway's 29-second limit.
By Bikram Nath · Curator · Updated June 2026
Frequently asked questions
What's the maximum Lambda timeout?
900 seconds (15 minutes). If your function needs more time, consider Step Functions for orchestrating long-running workflows, or move the work to ECS/Fargate which has no execution time limit.
Does increasing timeout cost more?
Only if the function actually runs longer. Lambda bills per 1ms of actual execution time, not the configured timeout. Setting timeout to 300s but running in 5s costs the same as a 10s timeout running in 5s.
Why does my function time out only sometimes?
Intermittent timeouts usually mean cold starts (first invocation is slow, subsequent ones are fast) or downstream latency spikes (a database or API responding slowly under load). Add CloudWatch metrics for p99 duration to see the tail latency.