CloudWatch Metric Guide
ConcurrentExecutionsAWS Lambda CloudWatch metric
ConcurrentExecutions reports the number of Lambda function instances actively processing events at any given time, across the entire account or per function when filtered by function name.
What it measures
About ConcurrentExecutions
ConcurrentExecutions reports the number of Lambda function instances actively processing events at any given time, across the entire account or per function when filtered by function name.
| Namespace | AWS/Lambda |
| Metric name | ConcurrentExecutions |
| Unit | Count |
| AWS docs | Official AWS Lambda metrics reference |
Why this metric matters
ConcurrentExecutions is the leading indicator for throttle pressure. By the time Throttles metric shows non-zero values, you've already dropped invocations. Tracking ConcurrentExecutions gives you the runway to act before throttles begin.
AWS publishes a default account-level concurrency limit of 1,000 unreserved concurrent executions. This limit is shared across all Lambda functions in the account that don't have reserved concurrency. At 800 concurrent executions on a 1,000-limit account, you have 200 executions of headroom — a burst of 300 simultaneous events will throttle 100 of them. That's a concrete number you can act on.
Recommended alarm threshold for ConcurrentExecutions
Recommended threshold
> 800 concurrent executions at the account level (for accounts at the default 1,000 limit)
The account-level concurrency limit is 1,000 by default per AWS documentation (this limit can be increased via a service quota increase request). The 80% threshold — 800 for a 1,000-limit account — (ConvOps recommendation) gives time to either request a limit increase or add reserved concurrency to isolate critical functions before throttles begin. Adjust the threshold if your account has a custom concurrency limit.
Is your ConcurrentExecutions alarm already set up correctly?
The free ConvOps Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including ConcurrentExecutions — in 5 minutes.
Common failures that show up in ConcurrentExecutions
When ConcurrentExecutions reaches an alarm threshold, these are the most common root causes — in order of how often ConvOps sees them across customer AWS accounts.
Event fan-out — a single S3 upload triggers processing of thousands of records, each dispatching its own Lambda invocation simultaneously
Retry storms — a downstream failure causes invocations to fail, Lambda retries them, and the combined in-flight + retry count saturates the concurrency limit
Scheduled job overlap — a cron-triggered Lambda runs longer than its schedule interval, causing multiple instances to run simultaneously
Insufficient reserved concurrency isolation — critical functions share the unreserved pool with background jobs
VPC cold start queue — when scaling out in a VPC, ENI attachment requests queue, causing in-progress invocations to pile up while they wait
How ConvOps debugs ConcurrentExecutions alarms
When ConcurrentExecutions triggers an alarm, ConvOps Diagnose reads CloudWatch Logs, CloudTrail (recent API calls, deploys, config changes), and the current resource state in parallel. It correlates these with AWS/Lambda metrics on the same resource — giving you a plain-English root cause with numbered fix options, sent to WhatsApp or Slack, usually within 60 seconds of the alarm firing.
Before any anomaly in ConcurrentExecutions reaches you as a proactive alert (via ConvOps Watch), it passes through 9 verification checks: a Recovery check (did the metric self-heal?), an AWS Status check (is AWS itself having an incident?), a Deploy check (was there a recent Lambda update, ECS deploy, or RDS parameter change in the last 120 minutes?), a Quota check, an Infrastructure check, a Security check, a Flap check (has this metric been anomalous more than 5 times in the last 24 hours?), a TLS check, and a Vulnerability check. Only anomalies that pass all relevant checks reach you — with full context attached.
ConvOps Watch
Detects ConcurrentExecutions anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a ConcurrentExecutions alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
ConvOps Audit
Scans your CloudWatch setup for missing or misconfigured ConcurrentExecutions alarms. Free, 5-minute read-only scan.
FAQ
Frequently asked questions about ConcurrentExecutions
Common questions about setting up CloudWatch alarms for ConcurrentExecutions in AWS Lambda.
What is the recommended CloudWatch alarm threshold for ConcurrentExecutions?+
> 800 concurrent executions at the account level (for accounts at the default 1,000 limit). The account-level concurrency limit is 1,000 by default per AWS documentation (this limit can be increased via a service quota increase request). The 80% threshold — 800 for a 1,000-limit account — (ConvOps recommendation) gives time to either request a limit increase or add reserved concurrency to isolate critical functions before throttles begin. Adjust the threshold if your account has a custom concurrency limit.
Which CloudWatch namespace does ConcurrentExecutions belong to?+
ConcurrentExecutions is published in the AWS/Lambda namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/Lambda". See the AWS Lambda CloudWatch metrics reference in the AWS documentation.
Does ConvOps automatically create CloudWatch alarms for ConcurrentExecutions?+
ConvOps does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free ConvOps Audit scans your CloudWatch setup and tells you which AWS Lambda resources are missing a ConcurrentExecutions alarm. ConvOps Watch then monitors ConcurrentExecutions using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use ConvOps without already having a ConcurrentExecutions alarm set up?+
Yes. ConvOps Watch monitors ConcurrentExecutions independently of your CloudWatch alarm configuration — it reads the metric directly from CloudWatch every 5 minutes on the Growth plan. If you run the free Audit first, it will tell you which resources need a ConcurrentExecutions alarm and provide the copy-paste AWS CLI command to create it.