CloudWatch Metric Guide
ThrottledRequestsAmazon DynamoDB CloudWatch metric
ThrottledRequests counts requests to DynamoDB that were throttled because the request rate exceeded the provisioned throughput limits for the table or index.
What it measures
About ThrottledRequests
ThrottledRequests counts requests to DynamoDB that were throttled because the request rate exceeded the provisioned throughput limits for the table or index.
| Namespace | AWS/DynamoDB |
| Metric name | ThrottledRequests |
| Unit | Count |
| AWS docs | Official Amazon DynamoDB metrics reference |
Why this metric matters
DynamoDB ThrottledRequests is the downstream consequence of ConsumedReadCapacityUnits or ConsumedWriteCapacityUnits exceeding provisioned limits. Where the capacity metrics tell you how close you are to the limit, ThrottledRequests tells you you've already crossed it.
Throttled requests are not dropped silently — the AWS SDK's built-in retry with exponential backoff re-attempts them. But this retry behavior has real costs: latency spikes (each retry adds delay), CPU overhead on the retry logic, and — critically — retries increase the request rate to DynamoDB, which can compound the throttling if the root cause is a traffic burst rather than insufficient provisioned capacity.
Recommended alarm threshold for ThrottledRequests
Recommended threshold
> 0 for provisioned capacity tables; > 0 as a cost and latency alert for on-demand tables
Any throttled request means at least one application request did not complete as expected and had to retry (ConvOps recommendation). Zero tolerance is the correct baseline for production. Sustained throttling that the SDK retries through may not generate application errors — but it is adding latency and masking an under-provisioning problem. Both provisioned and on-demand tables can throttle; on-demand tables throttle at very high request rates or during extremely rapid traffic growth.
Is your ThrottledRequests alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including ThrottledRequests — in 5 minutes.
Common failures that show up in ThrottledRequests
When ThrottledRequests reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Provisioned capacity too low for current workload — traffic has grown beyond the provisioned RCU/WCU since the last capacity adjustment
Auto-scaling lag — DynamoDB auto-scaling increases capacity in response to sustained consumption, but the increase takes time; rapid spikes throttle before the adjustment takes effect
Hot partition key — items with the same partition key hash receive disproportionate traffic, exceeding the per-partition throughput limit regardless of table-level provisioning
Burst of write operations — a bulk data load, migration, or import runs write operations faster than the table's write capacity can absorb
Underestimated on-demand table growth — on-demand capacity handles sudden traffic spikes up to double the table's previous peak; growth beyond twice the previous peak causes throttling
How Nuberio debugs ThrottledRequests alarms
When ThrottledRequests 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/DynamoDB 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 ThrottledRequests 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 ThrottledRequests anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
Nuberio Diagnose
When a ThrottledRequests 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 ThrottledRequests alarms. Free, 5-minute read-only scan.
Related Amazon DynamoDB metrics
ThrottledRequests rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon DynamoDB coverage.
FAQ
Frequently asked questions about ThrottledRequests
Common questions about setting up CloudWatch alarms for ThrottledRequests in Amazon DynamoDB.
What is the recommended CloudWatch alarm threshold for ThrottledRequests?+
> 0 for provisioned capacity tables; > 0 as a cost and latency alert for on-demand tables. Any throttled request means at least one application request did not complete as expected and had to retry (ConvOps recommendation). Zero tolerance is the correct baseline for production. Sustained throttling that the SDK retries through may not generate application errors — but it is adding latency and masking an under-provisioning problem. Both provisioned and on-demand tables can throttle; on-demand tables throttle at very high request rates or during extremely rapid traffic growth.
Which CloudWatch namespace does ThrottledRequests belong to?+
ThrottledRequests is published in the AWS/DynamoDB namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/DynamoDB". See the Amazon DynamoDB CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for ThrottledRequests?+
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 Amazon DynamoDB resources are missing a ThrottledRequests alarm. Nuberio Watch then monitors ThrottledRequests 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 ThrottledRequests alarm set up?+
Yes. Nuberio Watch monitors ThrottledRequests 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 ThrottledRequests 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 Amazon DynamoDB alarms your account is missing — including ThrottledRequests — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.