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 (Nuberio 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 the Nuberio Audit checks ThrottledRequests
The free Audit scans every Amazon DynamoDB resource in your account and checks whether a ThrottledRequests alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
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 (Nuberio 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?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon DynamoDB resources are missing a ThrottledRequests alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a ThrottledRequests alarm set up?+
Yes. The free Audit works whether or not you have any ThrottledRequests alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus 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, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. 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.