D

AWS Lambda Handler Error

Diagnose a Lambda function failing at invocation, timeout, or inside handler code.

On this page

Read the actual invocation result first

aws lambda invoke --function-name my-function --payload '{}' response.json

A synchronous invoke returns the function's actual error and stack trace in the response, before you even need to go look at logs.

cat response.json

Shows the error type and message Lambda captured directly from the handler.

Check CloudWatch Logs for the full trace

aws logs tail /aws/lambda/my-function --since 15m

Every invocation's logs, including anything the handler printed before it errored — the response.json error is often truncated compared to the full log entry.

Distinguish a timeout from a crash

A crash produces a stack trace pointing at a specific line. A timeout produces a generic Task timed out after N.NN seconds with no application stack trace at all — the process was killed mid-execution, not raising an error itself.

aws lambda get-function-configuration --function-name my-function --query Timeout

Checks the configured timeout against how long the function actually needs — a dependency that got slower, or a cold start eating into a tight timeout, both produce this.

Check for a permissions error masquerading as a handler bug

An AccessDenied calling another AWS service from inside the handler looks like an application error but is actually IAM — check the function's execution role.

aws lambda get-function --function-name my-function --query Configuration.Role

Shows the execution role attached to the function, to check its policy against whatever it's trying to call.

Check memory, not just timeout

Lambda's CPU allocation scales with configured memory — a function that's slow specifically under load (not consistently) may be memory/CPU-starved rather than genuinely timing out on logic. Check the REPORT line in logs for Max Memory Used against the configured limit.

Cold starts

A cold start (a new execution environment being initialized) adds latency before the handler even runs — especially noticeable with a large deployment package, a VPC-attached function, or a runtime with heavy initialization (loading ML models, opening many connections at import time). Not an error, but a common cause of a request that's slow specifically the first time in a while.