AWS Lambda Error: Function timed out after X seconds

Why Lambda times out and how to diagnose slow code paths, blocked VPC traffic, or downstream latency.

Problem

Your Lambda runs but never completes within the configured timeout period. Eventually AWS terminates the execution and returns the error “Task timed out after X seconds.” This often happens when the function depends on slow downstream services, has an inefficient code path, or is placed inside a VPC subnet with restricted or missing network access.

{
  "errorMessage": "Task timed out after 6.00 seconds",
  "errorType": "TimeoutError"
}

Top three causes at a glance:

Slow or unresponsive downstream services holding the execution open
VPC networking issues blocking outbound calls until timeout
Inefficient or long-running code paths that exceed your configured duration

Clarifying the Issue

A timeout occurs when Lambda reaches the maximum allowed execution duration (timeout setting) and the function still hasn’t returned. This may be due to network calls that never return, downstream API latency, database timeouts, Python/Node event-loop gaps, large initialization overhead, or any workflow that simply takes longer than the configured limit. Lambda forcibly terminates the runtime, leaving operations incomplete.

Key diagnostic insights:

Lambda kills the runtime when execution exceeds the function’s timeout
Most timeouts stem from slow network calls, event-loop delays, or cold starts
VPC configuration can drastically increase latency or block external connectivity

Why It Matters

Timeouts often mask deeper issues such as blocked outbound traffic, DNS misconfiguration inside VPCs, slow database queries, or inefficient code paths. In production this leads to failed requests, partial writes, stalled event pipelines, and unpredictable retry behavior. Fixing timeouts quickly improves system reliability, reduces operational load, and restores normal function behavior.

Business and operational impact:

Incomplete operations can cascade into upstream and downstream failures
Retries multiply load and may worsen instability if the root cause persists
Persistent timeouts often signal architectural issues requiring correction

Key Terms

Timeout – Maximum wall-clock execution time allowed for a Lambda function
Cold start – Initialization period before the handler runs
VPC-enabled Lambda – A Lambda attached to private subnets and ENIs
Downstream service – Any API, DB, or system your function depends on

Steps at a Glance

Inspect CloudWatch logs for the timeout pattern.
Identify long-running operations or hanging network calls.
Validate whether the function runs inside a VPC.
Test outbound network access if VPC-enabled.
Measure execution time locally or in a sandbox.
Increase the Lambda timeout only if needed.
Optimize code paths and dependency initialization.
Re-deploy and test the function again.

Detailed Steps

Step 1: Inspect CloudWatch logs for the timeout pattern.

Start by reviewing recent logs to confirm the timeout and assess when the function stopped running.

aws logs tail /aws/lambda/my-function --since 5m

If you see repeated lines ending with Task timed out after X.XX seconds, Lambda terminated execution upon reaching your configured timeout.

With the timeout confirmed, determine what the function was doing immediately before it hung.

Step 2: Identify long-running operations or hanging network calls.

Check for outbound API calls or operations that started but never logged completion.

aws logs tail /aws/lambda/my-function --since 5m | grep -i "http"

If outbound HTTP calls appear without corresponding responses, the function is waiting indefinitely on a downstream service.

Once you understand whether a network call or heavy compute is causing the delay, identify whether your function is running inside a VPC.

Step 3: Validate whether the function runs inside a VPC.

Retrieve the Lambda configuration to determine if the function is VPC-attached.

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'VpcConfig'

If VpcConfig contains subnets and security groups, the function is VPC-enabled — a common root cause of timeouts.

Now check whether outbound traffic is actually working.

Step 4: Test outbound network access if VPC-enabled.

Private subnets without NAT access block external calls, forcing Lambdas to hang until they time out. Run a simple test invocation to probe outbound connectivity.

aws lambda invoke \
  --function-name my-function \
  --payload '{"test":"dns"}' \
  out.json

If logs show DNS failures (ENOTFOUND) or no outbound response, your VPC configuration is blocking traffic.

After validating VPC conditions, measure local execution to identify slow code paths.

Step 5: Measure execution time locally or in a sandbox.

Time your core logic outside Lambda to understand its baseline performance.

time python3 app.py

If your code takes longer locally than your Lambda timeout, either optimize or increase the timeout.

Once you understand baseline execution, evaluate whether increasing the timeout is appropriate.

Step 6: Increase the Lambda timeout only if needed.

If the function simply needs more time to complete valid work, increase the timeout value.

aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

This sets the timeout to 30 seconds. The maximum is 900 seconds (15 minutes).

After adjusting the timeout, optimize slow sections to improve consistency.

Step 7: Optimize code paths and dependency initialization.

Investigate slow imports, heavy libraries, or inefficient loops. Measure import overhead in Python:

python3 -X importtime app.py

This reveals dependencies that cause slow cold starts or initialization delays.

After trimming unnecessary overhead, redeploy and test again.

Step 8: Re-deploy and test the function again.

Upload any code or configuration changes.

aws lambda invoke \
  --function-name my-function \
  --payload '{}' \
  out.json

A "StatusCode": 200 indicates the function completed within the timeout.

If the timeout persists, revisit VPC networking, DNS configuration, and downstream service performance.

Pro Tips

Test outside the VPC first.

Deploy a temporary non-VPC version. If the timeout disappears, the root cause is VPC networking or DNS.

Warm functions reduce latency.

Scheduled CloudWatch triggers keep Lambdas warm, reducing cold start impact.

Add fine-grained timing logs.

Timestamp logs before and after every major operation to pinpoint slow segments.

Conclusion

Function timeouts occur when execution exceeds the Lambda timeout limit, often due to networking issues, downstream latency, or inefficient code paths. By analyzing logs, reviewing VPC configuration, measuring performance, and tuning initialization, you can eliminate persistent timeouts and improve overall system reliability.

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.

Search This Blog

Tech-Reader.blog