Lambda functions with a timeout over 300 seconds and 5x their longest observed run

The timeout is a ceiling, not a price

Lambda functions are priced per request and execution duration, with duration measured from the time your code begins executing until it returns or terminates. The timeout setting defaults to 3 seconds and can be raised to 900 seconds (15 minutes). Setting it high costs nothing while the function behaves.

The risk shows up when it does not. A function stuck on a dead downstream connection runs, and bills, until the timeout, so a 15-minute ceiling on a function that normally finishes in two seconds turns every hang into roughly 450 times the normal charge, and holds concurrency the whole time.

Comparing timeouts with real run times

aws lambda list-functions \
  --query 'Functions[?Timeout>`300`].[FunctionName,Timeout,MemorySize]' --output table

aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda --metric-name Duration \
  --dimensions Name=FunctionName,Value=my-function \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 86400 --statistics Maximum

Duration is reported in milliseconds, per the Lambda metrics reference, while the timeout is in seconds.

Two numbers compared

ZopNight reads the function’s configured timeout and needs it to be above 300 seconds. It then takes the peak Duration over the last 30 days, which must have at least 7 days of coverage and be greater than zero, and fires when the timeout is at least 5 times that peak. A function with a 900-second timeout whose longest run in a month was 60 seconds qualifies; one whose longest run was 200 seconds does not. The function also needs a monthly cost in ZopNight’s data.

When a high timeout is left alone

Timeouts of 300 seconds or less are never flagged. Functions with no Duration data, too little history, or a peak within a factor of 5 of the timeout get no finding, since the ceiling may reflect a real long run. Functions with no price are skipped.

A hygiene finding with a $0 saving

The recommendation reports the function’s current monthly cost with no change after the fix, because steady-state cost depends on actual duration. The value is a smaller blast radius for hung invocations.

Setting a tighter timeout

1. Look at the observed peak Duration and the p99 over a longer period if you have it.
2. Pick a timeout of about twice the observed peak, leaving headroom.
3. Apply it: aws lambda update-function-configuration --function-name my-function --timeout 120.
4. For work that genuinely runs long, consider Step Functions or ECS instead of a large Lambda timeout.