Debugging Lambda Timeouts
Run a structured AWS Lambda timeout investigation using configuration, CloudWatch metrics and logs, dependencies, and optional source review.
Overview
Debugging Lambda Timeouts is an agent skill for the Operate phase that systematically investigates AWS Lambda timeout failures via configuration, CloudWatch data, dependencies, and optional code review.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill debugging-lambda-timeoutsWhat is this skill?
- Collects required inputs in one prompt: function_name, region, optional time_window_hours and lambda_code
- Analyzes timeout settings, external latency, DB connections, memory, and inefficient code patterns
- Configurable lookback window (default 1 hour) for metrics and log correlation
- Optional code path when lambda_code is supplied; otherwise configuration-and-metrics focus
- Outputs specific resolution recommendations, not generic timeout advice
- Default metrics lookback: 1 hour (time_window_hours optional)
Adoption & trust: 978 installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Lambda keeps timing out and you are stuck toggling timeout seconds without knowing whether the bottleneck is config, dependencies, or code.
Who is it for?
Solo builders shipping APIs or background jobs on Lambda who need a repeatable timeout RCA after deploy.
Skip if: Greenfield architecture picks or local-only runtimes with no AWS function name and region to inspect.
When should I use this skill?
Lambda functions fail with timeout errors and you have function_name and region to analyze.
What do I get? / Deliverables
You get a prioritized list of likely timeout causes and concrete fixes aligned to your function, region, and analysis window.
- Timeout root-cause analysis for the chosen time window
- Actionable configuration and code recommendations
Recommended Skills
Journey fit
Timeouts surface in production serverless workloads and need operational triage before scaling or redeploying. Timeout failures are runtime error incidents; this SOP targets diagnosis and remediation of those failures.
How it compares
Use this structured SOP instead of ad-hoc CloudWatch clicking when timeouts need correlated config, metrics, and code context.
Common Questions / FAQ
Who is debugging-lambda-timeouts for?
Indie and solo builders operating serverless APIs or workers on AWS who want agent-guided timeout root-cause analysis.
When should I use debugging-lambda-timeouts?
Use it in Operate when invocations fail on timeout, after deploy regressions, or when p95 duration approaches the configured limit; also when validating Ship perf fixes in production.
Is debugging-lambda-timeouts safe to install?
Review the Security Audits panel on this Prism page and scope any AWS credentials and network access before the agent runs dependency or API checks.
SKILL.md
READMESKILL.md - Debugging Lambda Timeouts
# Lambda Timeout Debugging ## Overview This SOP systematically investigates Lambda function timeout failures by analyzing function configuration, CloudWatch logs, metrics, dependencies, and code patterns. It identifies common causes of timeouts such as insufficient timeout settings, external service delays, database connection issues, memory constraints, and inefficient code patterns, then provides specific recommendations for resolution. ## Parameters Prompt the user in a single message to provide all required parameters at once. Clearly list the required parameters and their descriptions, and include any optional parameters with their default values. Do not proceed until you have received and confirmed all required parameters. If any required parameter is missing or unclear, you MUST explicitly request the missing information before moving forward. - **function_name** (required): The name of the Lambda function experiencing timeout issues - **region** (required): The AWS region where the Lambda function is deployed - **time_window_hours** (optional, default: 1): Number of hours to look back for analysis (e.g., 1, 2, 8, 12, 24, etc) - **lambda_code** (optional): The Lambda function code to analyze for potential timeout issues. If provided, the agent will review the code, otherwise the analysis will focus on configuration and metrics only. Only proceed to the steps below if you have all required information. ## Steps ### 1. Verify Dependencies Check for required tools and warn the user if any are missing. **Constraints:** - You MUST verify the following tools are available in your context: - call_aws - You MUST ONLY check for tool existence and MUST NOT attempt to run the tools because running tools during verification could cause unintended side effects, consume resources unnecessarily, or trigger actions before the user is ready - You MUST inform the user about any missing tools with a clear message - You MUST ask if the user wants to proceed anyway despite missing tools - You MUST respect the user's decision to proceed or abort ### 2. Get Function Configuration Retrieve the Lambda function configuration to understand current timeout and memory settings. **Constraints:** - You MUST only use the `call_aws` tool with the command: `aws lambda get-function-configuration --function-name ${function_name} --region ${region}` - You MUST extract and save the following key information: - Timeout setting (in seconds) - Memory allocation (in MB) - Runtime version - Last modified date - Environment variables - VPC configuration (if applicable) - You MUST identify if the timeout setting is at the maximum limit (900 seconds for most functions) ### 3. Analyze CloudWatch Metrics Examine Lambda metrics to understand timeout patterns and performance trends. **Constraints:** - You MUST calculate the start time for metrics analysis using the time_window_hours parameter - You MUST only use the `call_aws` tool with the command: `aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Duration --dimensions Name=FunctionName,Value=${function_name} --start-time ${start_time} --end-time ${end_time} --period 3600 --statistics Average Maximum --region ${region}` - You MUST retrieve timeout error metrics using: `aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Errors --dimensions Name=FunctionName,Value=${function_name} --start-time ${start_time} --end-time ${end_time} --period 3600 --statistics Sum --region ${region}` - You MUST analyze the relationship between duration trends and timeout occurrences - You MUST remember all metric data for correlation analysis ### 4. Check Log Group Availability Verify the log group exists and determine the available time range for analysis. **Constraints:** - You MUST use the `call_aws` tool with the command: `aws logs describe-log-groups --log-group-name-prefix /aws/lambda/${function_name} --region ${region}` - You MUST check if the log gr