# Lambda Timeout Too High

> ZopNight flags functions whose configured timeout exceeds 300 seconds and sits at least 5x above the worst Duration actually observed in 30 days. Savings are $0 by construction, since Lambda bills actual runtime and never the ceiling. The finding is about bounding the blast radius of a hung invocation.

Source: https://zop.dev/integrations/aws/recommendations/lambda-timeout-too-high
Updated: 2026-08-19

---

## What a timeout ceiling does and does not cost

Lambda [charges request count times GB-seconds](https://aws.amazon.com/lambda/pricing/) of *actual* execution. The configured
timeout never appears in that formula: a function set to 900 seconds that runs for two
pays for two. So lowering a timeout saves nothing in steady state, and this rule says so
with an explicit $0 rather than multiplying cost by an invented fraction. What the ceiling
does govern is the worst case: a hung invocation (stuck dependency, infinite retry loop,
dead downstream) burns billable time until the ceiling stops it. A 900-second ceiling on
a 3-second function makes every hang 300 times more expensive than it needed to be, per
invocation, times however many invocations hang in parallel.

## Fired only against measured runtime

A high timeout alone proves nothing. Plenty of batch and ETL handlers legitimately run
long. The rule compares the ceiling against the function's real [Duration series](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html): it fires
only when the timeout exceeds 300 seconds *and* sits at least five times above the trusted
peak runtime observed across 30 days. A function peaking anywhere near its ceiling
abstains, since clipping it risks timing out work that genuinely needs the room. Absent
Duration data, or a peak the coverage cannot vouch for, also abstains: over-allocation is
never asserted unobserved.

## Compare your own ceiling to reality

```bash
aws lambda get-function-configuration --function-name my-fn --query 'Timeout'
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda --metric-name Duration \
  --dimensions Name=FunctionName,Value=my-fn \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 3600 --statistics Maximum
```

The first number in seconds against the second in milliseconds; a 5× gap reproduces the
finding.

## Setting it well

Twice the observed peak is a defensible ceiling, with headroom for a slow dependency without
financing an hour of hang. Set it with
`aws lambda update-function-configuration --timeout <seconds>`, and pair the change with a
Duration alarm near the new ceiling so a genuine runtime shift announces itself instead of
manifesting as timeouts. Functions that truly need many minutes are usually workflow
candidates: Step Functions or a container task expresses "long-running" better than a
maximal Lambda ceiling ever will.