Guides

AWS Lambda Timeout: The 15-Minute Limit, How to Increase It and Fix "Task timed out"

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 16 October 2026 · Last updated: 17 October 2026

"Task timed out after 3.00 seconds" means your Lambda function was still running when it hit its timeout. New functions created in the console start with a 3-second timeout, and the maximum is 900 seconds (15 minutes). Raise it under Configuration → General configuration, but also find out why it is slow: a function in a VPC that cannot reach S3 or the internet, a slow database query or connection, too little memory (which also means less CPU), or a job that is simply too long for Lambda.

aws lambda update-function-configuration --function-name orders-report --timeout 60
aws lambda update-function-configuration --function-name orders-report --memory-size 1024
aws logs tail /aws/lambda/orders-report --since 15m      # read the timing

A live example first

A Python function orders-report reads a CSV from S3 and writes a summary to DynamoDB. In testing it fails:

START RequestId: 5c1e... Version: $LATEST
END RequestId: 5c1e...
REPORT RequestId: 5c1e... Duration: 3003.45 ms Billed Duration: 3000 ms
       Memory Size: 128 MB Max Memory Used: 71 MB
2026-10-16T18:41:07Z 5c1e... Task timed out after 3.00 seconds

We add simple timing logs:

import time, boto3
s3 = boto3.client("s3")

def handler(event, context):
    t = time.time()
    obj = s3.get_object(Bucket="rb-orders-2026", Key="oct.csv")
    print("s3 get took", round(time.time() - t, 2), "s")

With the timeout raised to 30 seconds, the log shows the S3 call never returns. The function is attached to a VPC (to reach RDS) in private subnets with no NAT gateway, so it cannot reach the S3 endpoint at all.

The fix: add an S3 gateway VPC endpoint to the private route table (free) and a DynamoDB gateway endpoint. Now:

s3 get took 0.21 s
REPORT ... Duration: 1840.12 ms Memory Size: 128 MB

Then we raise memory to 512 MB. The same work finishes in about 600 ms. Friends, raising the timeout only showed us the problem. The endpoint fixed it.

Why does Lambda time out?

Lambda stops your function when the configured timeout is reached, whatever it is doing. Common reasons:

How do I fix it step by step?

1. Open CloudWatch Logs for the function and read the REPORT line (duration, memory used).
2. Raise the timeout to a sensible value (for example 30 or 60 seconds) to see the full picture.
3. Add timing logs around each external call, or turn on X-Ray active tracing.
4. If the function is in a VPC, check the subnets' route tables for a NAT gateway or endpoints.
5. Create SDK and database clients outside the handler so they are reused.
6. Try more memory (512 MB, 1024 MB) and compare duration and cost.
7. Set the timeout to a little above the normal duration, not the maximum, so stuck runs end quickly.

Fixes by runtime

Python (boto3)

Create clients at module level, and set client timeouts so a stuck call fails fast:

from botocore.config import Config
s3 = boto3.client("s3", config=Config(connect_timeout=3, read_timeout=10, retries={"max_attempts": 3}))

Node.js

Create the SDK v3 client outside the handler. Do not leave open handles (timers, DB connections) that keep the event loop busy. If you use callbacks with open connections, set context.callbackWaitsForEmptyEventLoop = false.

Java (Spring Cloud Function, plain handlers)

Cold starts can take seconds. Use SnapStart (for supported Java runtimes) or a larger memory size, and keep the initialisation work small.

.NET and Go

.NET benefits from more memory and ReadyToRun or Native AOT builds. Go functions start quickly; time-outs there are almost always network or downstream waits.

Databases (MySQL, PostgreSQL on RDS)

Each new connection takes time, and hundreds of concurrent functions can exhaust the database. Put RDS Proxy in front, reuse one connection per container, and add indexes for slow queries.

When 15 minutes is not enough

Also remember API Gateway's own integration timeout (29 seconds by default for REST APIs) and the Application Load Balancer timeout. For long work behind an API, accept the request, put it on SQS, return 202 Accepted, and let the client check a status URL.

Real example: right tool for the job

In 2023, the Amazon Prime Video team published a blog post about a video-quality monitoring service first built with AWS Step Functions and Lambda. At their scale, the many function calls and data transfers cost too much, and they moved that part into a single ECS service, reporting about 90% lower infrastructure cost for it. The lesson is not "avoid Lambda". It is: Lambda is great for short, event-driven tasks. Long or very chatty jobs may fit containers better.

Mistakes to avoid

1. Setting every function to 900 seconds. A stuck function then burns 15 minutes of cost each time.
2. Putting Lambda in a VPC without need. Only attach a VPC if it must reach private resources.
3. Creating clients inside the handler. You pay connection time on every call.

Summary table