Lambda functions whose timeout ceiling dwarfs their real runtime
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-156 |
| Category | performance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | lambda_timeout.go |
Where it applies
What a timeout ceiling does and does not cost
Lambda charges request count times GB-seconds 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: 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
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 MaximumThe 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.