A Lambda invocation timing out does not prove that the function did no work. A database write or external API call may have completed just before the response was lost, and the event-delivery path may retry the invocation.
Set the timeout to fit the actual work boundary
If a timeout occurs after a write, the same event may be delivered again. The diagram uses the processing record for order-42 to show how a retry can avoid repeating the same write.
Before increasing the Lambda timeout, measure which step takes too long. Set database and external API timeouts shorter than the function timeout so it does not wait blindly until the function is about to end. A queue, batch job, or different execution model may be more suitable for long-running work.
For example, an asynchronous order-42 event might be saved successfully just before the function reaches its time limit. The caller may not know whether the work succeeded. When the same event is delivered again, check both its event key and the stored result to avoid another write. In logs, distinguish starts, completions, and timeouts by key without recording request bodies or secrets.
Make processing idempotent when retries are possible
Design an idempotency key and state transitions so processing the same event twice does not charge twice or create duplicate records. When the outcome of an external call is uncertain, a simple retry is insufficient; you need a request identifier and a duplicate-prevention contract with the receiving system.
Retry behavior depends on the invocation path. Lambda asynchronous invocations can be retried after function errors or timeouts, but the caller decides whether to retry a synchronous invocation. For queue events, also consider queue visibility timeouts and failure-handling settings. Do not assume that every Lambda invocation receives the same number of automatic retries.
If a function receiving order-42 finishes the database write but times out before responding, two invocations of the function should still produce only one order record.
| Invocation | Event key | Write result |
|---|---|---|
| First | order-42 | Write succeeds; timeout occurs before response |
| Retry | order-42 | Key is already processed; duplicate write is skipped |
A processed-key list kept only in function memory may be empty in another execution environment. Use a shared atomic boundary, such as a unique key or conditional write in the data store. During debugging, check invocation success separately from whether the business data was committed.
Key takeaways
Whether a timeout is followed by a retry depends on how Lambda was invoked. Set time limits for both the function and its external calls, and handle events that may be redelivered with idempotency keys and explicit state. Measure the bottleneck and review the processing model before simply increasing the timeout.
