What is the maximum timeout for an AWS Lambda function?

900 seconds (15 minutes). Anything longer needs a different shape: Step Functions to orchestrate multiple invocations, ECS/Fargate for long-running containers, or splitting the job into queued chunks.

Why does my Lambda time out at 29 or 30 seconds when its timeout is higher?

Something upstream has its own limit. API Gateway's integration timeout defaults to 29 seconds (raisable on Regional REST APIs), and many SDK clients default to ~30-second request timeouts. The function may even keep running after the caller has already given up.

Does increasing Lambda memory make it faster?

Yes, for CPU-bound and many I/O-parsing workloads: CPU is allocated proportionally to memory, reaching about 1 vCPU at 1,769 MB. It is the only CPU knob Lambda gives you, and since cost is duration x memory, faster execution often offsets the higher rate.

Am I billed for the full configured timeout?

No. Billing is based on actual execution time (Billed Duration in the REPORT line), not the configured maximum. A generous timeout costs nothing extra by itself: it just changes how long a hung invocation can burn before being killed.

How do I see what the function was doing when it timed out?

By default you cannot: the environment is frozen and the log just ends with the timeout message. Add client timeouts so failures raise real exceptions before the deadline, log progress markers around slow calls, and enable X-Ray tracing to see which segment consumed the time.

Error reference

AWS Lambda Timeout: Why "Task Timed Out" Happens and How to Fix It

Updated July 27, 2026

In short

A Lambda timeout ("Task timed out after X seconds") means the invocation ran past the function's configured timeout (default 3 seconds, maximum 900 (15 minutes)) and was terminated mid-execution. First decide which problem you have: the work legitimately needs more time (raise the timeout with aws lambda update-function-configuration --timeout 30), a downstream call is hanging (set client timeouts shorter than the function timeout), or the function is CPU-starved at low memory settings. Behind API Gateway, the effective ceiling is its 29-second integration timeout regardless of your function setting.

start here

aws lambda update-function-configuration --function-name <name> --timeout 30

Diagnosis

Causes at a glance

Cause	How to recognize it	Fix
Timeout set too low for the workload	Duration consistently lands near the limit; work is legitimately slow	Raise the timeout (up to 900s); split truly long jobs into steps
Downstream call hanging	Duration hits the limit exactly; a DB/API call has no client timeout	Set client timeouts below the function timeout; add retries
Too little memory (CPU-starved)	CPU-bound work; doubling memory roughly halves duration	Raise --memory-size; CPU scales with it (~1 vCPU at 1,769 MB)
VPC networking misconfigured	Timeouts only on calls to the internet or AWS APIs from a VPC function	Add a NAT gateway or VPC endpoints; private subnets have no internet route
Cold-start initialization overhead	Only the first invocations are slow; REPORT shows a large Init Duration	Trim init work and bundle size; use provisioned concurrency or SnapStart

Read the REPORT line first

Every invocation writes a REPORT line to CloudWatch Logs with the numbers that decide the diagnosis: Duration vs your configured timeout, Init Duration (cold-start cost), and Max Memory Used vs Memory Size. Duration pinned exactly at the limit points to a hang; Duration growing with input size points to real work; high Init Duration points at cold starts.

REPORT RequestId: 8f5c...  Duration: 30000.12 ms  Billed Duration: 30000 ms
  Memory Size: 512 MB  Max Memory Used: 187 MB  Init Duration: 1450.22 ms

# aggregate across invocations (CloudWatch Logs Insights):
filter @type = "REPORT"
| stats max(@duration), avg(@duration), max(@initDuration) by bin(5m)

Step 1

Step 1: raise the timeout when the work is legitimate

The default of 3 seconds is a tripwire, not a recommendation. Set the timeout to comfortably above observed p99 duration, up to the 900-second maximum. Note the caller's ceiling too: API Gateway's integration timeout defaults to 29 seconds (raisable on Regional REST APIs), so a 60-second function behind it still fails the HTTP request at 29.

aws lambda update-function-configuration \
  --function-name my-fn --timeout 60

aws lambda get-function-configuration \
  --function-name my-fn --query "[Timeout,MemorySize]"

Step 2

Step 2: put timeouts on every downstream call

A function that times out at exactly its limit is almost always waiting on something (a database, an external API, an LLM endpoint) with no client-side timeout. Default HTTP client timeouts are frequently infinite or longer than any sane Lambda timeout. Set connect and read timeouts so the function fails fast with a real error message instead of dying silently at the deadline.

# Python (botocore)
from botocore.config import Config
config = Config(connect_timeout=3, read_timeout=10, retries={'max_attempts': 2})

// Node.js fetch
await fetch(url, { signal: AbortSignal.timeout(10_000) });

Step 3

Step 3: add memory to get CPU

Lambda allocates CPU proportionally to memory: about one full vCPU at 1,769 MB, up to 6 vCPUs at 10,240 MB. CPU-bound functions at 128-256 MB are running on a sliver of a core, and "timeouts" are really just slow execution. Since billing is duration x memory, doubling memory that halves duration costs roughly the same, and finishes.

aws lambda update-function-configuration \
  --function-name my-fn --memory-size 1024

Step 4

Step 4: fix VPC egress and cold starts

A VPC-attached function in a private subnet has no route to the internet unless the subnet has a NAT gateway; calls to external APIs (and AWS APIs without VPC endpoints) hang until the timeout. This produces the classic "works outside the VPC, times out inside it" signature.

For cold starts, the REPORT Init Duration tells you the cost: shrink bundles and lazy-load SDKs, move heavy init out of the handler path, and for latency-critical routes use provisioned concurrency (any runtime) or SnapStart (Java, Python 3.12+, .NET 8+).

Ephemeral storage and other hidden limits

Functions get 512 MB of /tmp by default, configurable up to 10,240 MB (--ephemeral-storage). Jobs that stream large files through /tmp can stall or fail in ways that surface as timeouts. Also remember the 6 MB synchronous payload limit and that the Lambda service abandons the execution environment at timeout: no cleanup code runs, so anything not idempotent should be designed for replay.

Beyond the one-off fix

The fastest-growing cause of Lambda timeouts is the slowest dependency in modern stacks: LLM API calls, which can take 30-120 seconds under load. When those calls come from AI agents, a timeout is not just latency. It is spend with no result. Nexus tracks every model call an agent makes with latency and token cost attribution, so you can see which agent, which model, and which prompt pattern is burning your invocation budget before the timeout fires.

Explore Swfte Nexus

Common questions

What is the maximum timeout for an AWS Lambda function?: 900 seconds (15 minutes). Anything longer needs a different shape: Step Functions to orchestrate multiple invocations, ECS/Fargate for long-running containers, or splitting the job into queued chunks.
Why does my Lambda time out at 29 or 30 seconds when its timeout is higher?: Something upstream has its own limit. API Gateway's integration timeout defaults to 29 seconds (raisable on Regional REST APIs), and many SDK clients default to ~30-second request timeouts. The function may even keep running after the caller has already given up.
Does increasing Lambda memory make it faster?: Yes, for CPU-bound and many I/O-parsing workloads: CPU is allocated proportionally to memory, reaching about 1 vCPU at 1,769 MB. It is the only CPU knob Lambda gives you, and since cost is duration x memory, faster execution often offsets the higher rate.
Am I billed for the full configured timeout?: No. Billing is based on actual execution time (Billed Duration in the REPORT line), not the configured maximum. A generous timeout costs nothing extra by itself: it just changes how long a hung invocation can burn before being killed.
How do I see what the function was doing when it timed out?: By default you cannot: the environment is frozen and the log just ends with the timeout message. Add client timeouts so failures raise real exceptions before the deadline, log progress markers around slow calls, and enable X-Ray tracing to see which segment consumed the time.