# Lambda Functions Frequently Timing Out | Cloud Efficiency Hub Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/lambda-functions-frequently-timing-out A Lambda invocation that hits its configured timeout is stopped by the runtime and returned as a function error, but the time it ran up to that limit... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version A Lambda invocation that hits its configured timeout is stopped by the runtime and returned as a function error, but the time it ran up to that limit is still billed. PointFive Research Cloud cost research at PointFive AWS service [AWS Lambda](https://www.pointfive.co/efficiency-hub/cloud-services/aws-lambda) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0358 Type Inefficient Configuration ## Explanation Why the waste happens and who it affects. The work it was doing is usually lost, so the invocation is paid for in full while producing nothing. When the invoker retries - Lambda retries failed asynchronous invocations up to two times by default, stream event source mappings retry the whole batch, and SQS returns the message to the queue - the same doomed work is paid for again, often at the maximum duration each time. Common causes are downstream calls that are slower than expected, larger than expected payloads, and AWS SDK or HTTP clients whose default connect and read timeouts are longer than the function timeout, so a hung connection runs the function all the way to its limit instead of failing fast. The problem affects functions of any size, but it is most expensive on functions with high memory settings, long timeouts and high invocation volume. ## Billing model The pricing dimensions that drive this cost. Lambda bills every invocation, including ones that end in a timeout. Request charge Billed per invocation, including invocations that fail or time out and every retry attempt Duration Billed in GB-seconds from when code begins executing until it returns or otherwise terminates, rounded up to the nearest 1 ms, so a timed-out invocation is billed for the full time it ran up to the timeout Retries Asynchronous invocations are retried up to two times by default after function errors, and each retry is billed as a new request plus its duration ## How to detect 5 checks to find it in your estate. - Review the Trusted Advisor cost optimization check AWS Lambda functions with excessive timeouts , which flags functions where more than 10% of invocations end in an error due to a timeout on any given day within the last 7 days and reports the timeout rate and the lost daily compute cost - Search the function's CloudWatch Logs for "Task timed out after" messages and count them against the Invocations metric over the same period - Compare the Duration metric's Maximum and p99 statistics with the configured timeout; a cluster of invocations at exactly the timeout value indicates invocations being cut off rather than completing - Check whether the Errors metric rises together with invocation counts, AsyncEventAge or IteratorAge, which suggests timed-out work is being retried - Use X-Ray traces or log statements around API and database calls to find which downstream call is consuming the time ## How to fix 5 ways to remove the waste. - Set AWS SDK and HTTP client connect timeouts, read timeouts and retry counts so that calls fail or retry within the function timeout instead of running to the limit; AWS notes that default SDK client timeouts may be longer than the configured function duration - Fix or isolate the slow dependency found in traces, for example by adding connection reuse, reducing payload size or moving long waits into an asynchronous pattern - Increase the function timeout only when the expected duration of legitimate work is longer than the current setting, and test with data sizes at the upper bound of what the workload receives - Limit repeated paid retries of work that will keep timing out by setting MaximumRetryAttempts and maximum event age on asynchronous invocations, retry limits on stream event source mappings, and a redrive policy with a dead-letter queue on SQS sources - Alarm on the timeout rate per function so regressions after deployments or dependency changes are caught before they accumulate cost ## Documentation Vendor references for pricing and configuration. - [Cost optimization - AWS Support docs.aws.amazon.com](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html) - [Configure Lambda function timeout docs.aws.amazon.com](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html) - [Understanding retry behavior in Lambda docs.aws.amazon.com](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) - [Types of metrics for Lambda functions docs.aws.amazon.com](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics-types.html) - [AWS Lambda Pricing aws.amazon.com](https://aws.amazon.com/lambda/pricing/) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - AWS Lambda CER-0204 ### [Inefficient SnapStart Configuration in Lambda](https://www.pointfive.co/efficiency-hub/inefficiencies/inefficient-snapstart-configuration-in-lambda) SnapStart reduces cold-start latency, but when configured inefficiently, it can increase costs. For Python and .NET functions, high-traffic workloads can trigger frequent snapshot restorations, multiplying costs. Slow initialization code... Compute - AWS Lambda CER-0230 ### [Excessive Lambda Duration from Synchronous Waiting](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-lambda-duration-from-synchronous-waiting) Some Lambda functions perform synchronous calls to other services, APIs, or internal microservices and wait for the response before proceeding. During this time, the Lambda is idle from a compute perspective but still fully billed. This... Compute - AWS Lambda CER-0218 ### [Suboptimal Architecture Selection in AWS Lambda](https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-architecture-selection-in-aws-lambda) Lambda functions default to the x86\_64 architecture, which is more expensive than Arm64. For many workloads, especially those written in interpreted languages (e.g., Python, Node.js) or compiled to architecture-neutral bytecode (e.g.,... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.