PacketSensei

AWS `Task timed out after N seconds`: What It Means and How to Fix It

PacketSensei

Task timed out after N seconds is a Lambda function killed at its configured timeout — often waiting on a network call that can never complete. It comes from Lambda, and the message reads:

Task timed out after 3.00 seconds

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error Task timed out after N seconds
Service Lambda
Message Task timed out after 3.00 seconds
Most common cause A VPC-attached function with no NAT gateway or endpoint

What it actually means

Lambda terminates the invocation when it reaches the configured timeout, which defaults to 3 seconds and can be raised to 15 minutes. The function is killed mid-execution: no cleanup, no finally block, no flush of buffered logs.

The interesting cases are not slow code. They are functions blocked on something that will never return, and the most common of those is a VPC-attached function with no route to the thing it is calling.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 A VPC-attached function with no NAT gateway or endpoint A Lambda in private subnets has no internet access by default. A call to a public API, or to an AWS service without a VPC endpoint, hangs until the timeout. The function works perfectly outside the VPC and times out inside it — a very recognisable signature.
2 A security group with no outbound rule Lambda ENIs need egress. A locked-down group with no outbound rule produces exactly the same hang.
3 A database connection storm PostgreSQL uses a process per connection. A burst of concurrent Lambdas exhausts max_connections and later invocations block waiting. RDS Proxy exists for this.
4 No client-side timeout configured SDK defaults are often longer than the Lambda timeout, so the function dies before the call gives up. Set client timeouts below the function timeout so you get a real error instead of a kill.
5 A cold start on a heavy runtime Large deployment packages, JVM startup, or a VPC ENI cold start eating most of a 3-second budget.
6 Genuinely slow work Sometimes it is just the code. Check the Duration metric distribution before assuming otherwise.

How to tell which one you have

# How close to the ceiling are invocations running?
aws cloudwatch get-metric-statistics --namespace AWS/Lambda \
  --metric-name Duration --dimensions Name=FunctionName,Value=my-function \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 3600 --statistics Average Maximum p99

# Is it in a VPC, and what is the configured timeout?
aws lambda get-function-configuration --function-name my-function \
  --query '[Timeout,MemorySize,VpcConfig.SubnetIds,VpcConfig.SecurityGroupIds]'

If VpcConfig.SubnetIds is non-empty, check that those subnets have a NAT gateway route or the relevant VPC endpoints before looking at the code at all.

X-Ray traces show exactly which call is hanging, and are worth enabling for a single deployment to answer the question definitively.

Preventing it

Set the timeout deliberately rather than leaving the default. A function calling a database should have a timeout modestly above its expected worst case, and SDK client timeouts set below it, so a slow dependency produces a catchable error rather than a kill.

Raise memory before optimising code: Lambda allocates CPU proportionally to memory, so a function at 1,024 MB often runs more than twice as fast as one at 512 MB and can cost the same or less. Measure with Lambda Power Tuning rather than guessing.

Add a CloudWatch alarm on Duration p99 approaching the timeout, so you find out before invocations start failing.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.