Task timed out after 30.00 seconds

What it means

Lambda gives every invocation a wall-clock budget. You set it per function, anywhere from one second to fifteen minutes, and the runtime enforces it with a hard stop: when the clock runs out, the execution environment is frozen and the invocation is marked failed. Your handler does not get an exception, a signal, or a chance to clean up. It simply stops existing between one instruction and the next.

That is why the number in the message is so often misread. Task timed out after 30.00 seconds does not mean the work took thirty seconds — it means your timeout is thirty seconds, and the work had not finished by then. It would say the same thing if the function were one second from done or if it were hung on a socket that was never going to answer. The message describes the limit, not the workload.

Three consequences follow, and all three cost money or correctness. You are billed for the full timeout, because the environment was reserved the whole time. Whatever your handler was about to return is discarded. And any side effect already in flight — a half-written batch, an open transaction, a message pulled from a queue but not yet deleted — is left exactly where it was, which is how a timeout on a retryable event source turns into duplicate work on the retry.

The distinction that actually matters when you are debugging is stuck versus slow. A stuck function is waiting on something that will never answer, and its logs stop dead at the call that hung. A slow function is making progress and simply runs out of road, and its logs keep advancing right up to the last millisecond. The fix for one is a timeout on the downstream call; the fix for the other is more time, more memory, or less work per invocation. Reading the last few lines before the cutoff tells you which one you have, and that is the whole reason it matters to see those lines grouped with their own invocation rather than interleaved with every other execution that was running at the same moment.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

Look for three things together. The Task timed out line is stamped with the request ID and appears instead of a normal handler return. The REPORT line for that same request ID shows a Duration equal to your configured timeout — 30000.00 ms for a 30-second timeout, to the millisecond — and on newer runtimes carries Status: timeout. And there is no END-then-result pattern: the last thing your own code logged is wherever it got to, which is the single most useful clue about what was slow.

The giveaway that separates a timeout from a crash: the duration is suspiciously round. A function that crashes stops at an arbitrary millisecond. A function that times out stops at exactly the number you configured.

Causes, most likely first

Fixes

jsimport { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { NodeHttpHandler } from "@smithy/node-http-handler";

const client = new DynamoDBClient({
  requestHandler: new NodeHttpHandler({
    connectionTimeout: 1000,   // give up on the TCP connect fast
    requestTimeout: 5000       // and on a hung response
  }),
  maxAttempts: 3
});

jsexport const handler = async (event, context) => {
  for (const batch of batches) {
    // Stop while there is still time to write a useful log line.
    if (context.getRemainingTimeInMillis() < 5000) {
      console.warn("Out of budget", {
        processed: done,
        remaining: batches.length - done
      });
      return { done, incomplete: true };
    }
    await process(batch);
  }
};

yaml# AWS SAM
Resources:
  ReconcileFunction:
    Type: AWS::Serverless::Function
    Properties:
      Timeout: 120        # seconds; hard maximum is 900
      MemorySize: 1024    # more memory also means more CPU

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Troubleshoot invocation issues
• AWS Lambda Developer Guide — Configuring function timeout