Fix: Task timed out after 3.00 seconds (Lambda)

Lambda enforces a hard wall clock limit per invocation, and when execution reaches it the runtime is killed mid flight and the invocation is recorded as Task timed out. The default timeout is 3 seconds, which is enough for trivial handlers and almost nothing else. The error tells you the function was still running at the deadline; it does not tell you why, and that is the real question: was the work legitimately slow, hung on a network call, or starved by a cold start?

Task timed out after 3.00 seconds (Lambda)

What this error means

Every Lambda function has a configured timeout between 1 second and 15 minutes. When an invocation exceeds it, the service terminates the execution environment, logs the timeout line to CloudWatch, and reports the invocation as failed. Whatever the handler was doing is abandoned: partial writes stay written, in flight HTTP calls are dropped, and for async invocations Lambda will retry, which means a timed out function that already did half its work can run again from the top. Timeouts therefore have two costs: the failure itself, and the duplicate side effects of retries against non idempotent work.

Common causes

• The default 3 second timeout was never changed and any real work (a database query, an external API call, a cold start) exceeds it.
• A downstream dependency is slow or hanging: a database under load, an unresponsive third party API, or an SDK call without its own timeout.
• VPC networking gaps: subnets without a NAT gateway or VPC endpoints make outbound calls hang until the deadline.
• Cold start initialization (large bundles, heavyweight clients, connection setup in global scope) consuming most of a short limit.
• Undersized memory: CPU scales with memory in Lambda, so a 128 MB function does CPU bound work several times slower than the same code at 1024 MB.
• Connection pool exhaustion on the database side, so invocations queue for a connection until they time out.

How to fix it

STABILIZE first. If a production path is failing on every invoke, raise the timeout to a value that covers observed duration plus headroom. That restores service while you find the real bottleneck.

1. Confirm the current configuration and raise it along with memory if the work is CPU bound:

aws lambda get-function-configuration \
  --function-name my-fn \
  --query '{Timeout:Timeout,MemorySize:MemorySize}'

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

2. DIAGNOSE where the time goes. Pull the timeout occurrences and the reported durations from the logs:

aws logs filter-log-events \
  --log-group-name /aws/lambda/my-fn \
  --filter-pattern "Task timed out" \
  --max-items 20

Check whether timeouts correlate with cold starts by looking at Init Duration in the REPORT lines, and enable X-Ray tracing to see which downstream call eats the budget:

aws lambda update-function-configuration \
  --function-name my-fn \
  --tracing-config Mode=Active

3. FIX the actual bottleneck. Set explicit timeouts on every outbound call inside the handler so a slow dependency fails fast with a useful error instead of burning the whole budget. Move clients and connections to global scope so warm invocations reuse them. For database heavy functions, use RDS Proxy so invocations do not fight over connections.

4. If the function hangs only inside a VPC, fix the routing: add a NAT gateway to the subnets or create VPC endpoints for the AWS services it calls, and verify security group rules in both directions.

5. If the work genuinely needs more than a couple of minutes, restructure instead of maxing the timeout: split it into steps with Step Functions, feed it through SQS in smaller batches, or move it to ECS or Batch where long runs belong.

How to prevent it

• Set every function’s timeout deliberately from measured duration, never leave the 3 second default on real workloads.
• Put explicit, shorter timeouts on all downstream calls so dependencies fail visibly instead of hanging to the deadline.
• Alarm on the function’s Duration approaching its timeout and on the Errors and Throttles metrics.
• Make handlers idempotent, since async retries after a timeout will re run partial work.
• Load test with realistic payloads, and size memory for the CPU the code actually needs.

When to call a senior engineer

Call for help when timeouts persist after raising limits and nobody can say where the time goes, when VPC networking, connection pooling, and cold starts interact into intermittent failures, or when retries of timed out functions are creating duplicate writes in production data. Erzon engineers can trace the invocation path end to end, pin the slow hop with real evidence, and restructure the function so it finishes fast and fails safely.