CloudWatch Metric Guide
ThrottlesAWS Lambda CloudWatch metric
Throttles counts invocation requests that Lambda rejected because concurrent execution limits were reached. A throttled invocation was not executed — the caller receives a 429 TooManyRequestsException.
What it measures
About Throttles
Throttles counts invocation requests that Lambda rejected because concurrent execution limits were reached. A throttled invocation was not executed — the caller receives a 429 TooManyRequestsException.
| Namespace | AWS/Lambda |
| Metric name | Throttles |
| Unit | Count |
| AWS docs | Official AWS Lambda metrics reference |
Why this metric matters
Throttles are silent drops — the caller is rejected, the function never ran, and no error appears in the function's own logs. For event-driven architectures, throttles can cause compounding failures: an SQS trigger that can't invoke the function backs up its queue, increasing message age and eventually expiring or sending to a dead-letter queue.
AWS sets a default account-level concurrency limit of 1,000 unreserved concurrent executions, as documented by AWS. Individual functions without reserved concurrency share this pool. A single bursty function can starve all other Lambda functions in the account by consuming the entire unreserved pool. Throttles on any function should be treated as an account-wide capacity signal.
Recommended alarm threshold for Throttles
Recommended threshold
> 0 for critical functions; for high-volume functions, a low absolute count threshold based on your acceptable drop rate
Any throttle on a synchronous, user-facing Lambda is an immediate user-visible failure — zero tolerance is correct (ConvOps recommendation). For async processing functions with retry logic, occasional throttles may be acceptable; set a threshold based on your measured retry success rate and dead-letter queue budget. AWS documentation recommends using reserved concurrency to isolate critical functions from account-level throttle pressure.
Is your Throttles alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including Throttles — in 5 minutes.
Common failures that show up in Throttles
When Throttles reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Account-level concurrency exhaustion — a high-traffic function consumes the unreserved pool, throttling all other Lambda functions in the account
Burst limit exceeded — Lambda allows a per-region burst limit (3,000 initial burst in most regions per AWS documentation) and throttles sudden spikes that exceed it
Reserved concurrency set too low — a function has explicit reserved concurrency that underestimates peak traffic
Fan-out amplification — an SNS or EventBridge rule fires for every record in a batch, generating N invocations simultaneously and hitting the concurrency limit
Downstream rate limiting — the function calls an API with a rate limit, fails, and Lambda's automatic retry doubles the concurrent invocations, compounding the throttle
How Nuberio debugs Throttles alarms
When Throttles triggers an alarm, Nuberio 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 Throttles reaches you as a proactive alert (via Nuberio 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.
Nuberio Watch
Detects Throttles anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
Nuberio Diagnose
When a Throttles alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured Throttles alarms. Free, 5-minute read-only scan.
Related AWS Lambda metrics
Throttles rarely fails in isolation. These metrics tend to correlate — monitor them together for complete AWS Lambda coverage.
FAQ
Frequently asked questions about Throttles
Common questions about setting up CloudWatch alarms for Throttles in AWS Lambda.
What is the recommended CloudWatch alarm threshold for Throttles?+
> 0 for critical functions; for high-volume functions, a low absolute count threshold based on your acceptable drop rate. Any throttle on a synchronous, user-facing Lambda is an immediate user-visible failure — zero tolerance is correct (ConvOps recommendation). For async processing functions with retry logic, occasional throttles may be acceptable; set a threshold based on your measured retry success rate and dead-letter queue budget. AWS documentation recommends using reserved concurrency to isolate critical functions from account-level throttle pressure.
Which CloudWatch namespace does Throttles belong to?+
Throttles 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 Nuberio automatically create CloudWatch alarms for Throttles?+
Nuberio does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free Nuberio Audit scans your CloudWatch setup and tells you which AWS Lambda resources are missing a Throttles alarm. Nuberio Watch then monitors Throttles using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use Nuberio without already having a Throttles alarm set up?+
Yes. Nuberio Watch monitors Throttles 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 Throttles alarm and provide the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, and DynamoDB. To find which AWS Lambda alarms your account is missing — including Throttles — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.