CloudWatch Metric Guide
SuccessfulRequestLatencyAmazon DynamoDB CloudWatch metric
SuccessfulRequestLatency measures the elapsed time for successful requests to DynamoDB or DynamoDB Streams, broken down by the TableName and Operation dimensions. It reflects latency inside DynamoDB only — not network or client-side time.
What it measures
About SuccessfulRequestLatency
SuccessfulRequestLatency measures the elapsed time for successful requests to DynamoDB or DynamoDB Streams, broken down by the TableName and Operation dimensions. It reflects latency inside DynamoDB only — not network or client-side time.
| Namespace | AWS/DynamoDB |
| Metric name | SuccessfulRequestLatency |
| Unit | Milliseconds |
| AWS docs | Official Amazon DynamoDB metrics reference |
Why this metric matters
Capacity and throttling metrics tell you when DynamoDB is refusing requests outright. SuccessfulRequestLatency tells you something more subtle and often more common: requests are succeeding but getting slower, which erodes user experience long before any error shows up in logs. Because this metric is dimensioned by Operation (GetItem, Query, Scan, PutItem, and so on), it's also the fastest way to isolate which access pattern is degrading — a slow Scan on a reporting job looks nothing like a slow GetItem on a hot key, and conflating them wastes debugging time.
DynamoDB is marketed around consistently low, single-digit-millisecond latency for simple key-based operations at any scale (per AWS's own DynamoDB product page). That baseline is a starting expectation, not a documented SLA or CloudWatch-published number — so a useful alarm is relative to your own table's normal p99, not a single global number. A Query or Scan without a selective key condition, a hot partition under contention, or a large item size can all push latency well above that baseline even while every request still returns HTTP 200.
Recommended alarm threshold for SuccessfulRequestLatency
Recommended threshold
p99 SuccessfulRequestLatency for a given Operation sustained noticeably above that operation's own rolling baseline (e.g., 2–3x the typical p99 for 5+ minutes)
AWS does not publish a specific alarm threshold for this metric — DynamoDB's own marketing describes single-digit-millisecond performance for simple operations as a general characteristic, not a per-table SLA (per aws.amazon.com/dynamodb). A relative, per-Operation baseline (Nuberio recommendation) is more reliable than a fixed millisecond cutoff, because expected latency varies significantly by operation type (GetItem vs. Query vs. Scan), item size, and whether DAX or strongly consistent reads are in use.
Is your SuccessfulRequestLatency alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including SuccessfulRequestLatency — in 5 minutes.
Common failures that show up in SuccessfulRequestLatency
When SuccessfulRequestLatency reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Scan or unselective Query — operations that read far more items than they return spend more time server-side, inflating latency for that Operation dimension specifically
Hot partition contention — concurrent requests hitting the same partition key queue behind each other at the storage layer, raising tail latency even when average table-level capacity looks fine
Large item sizes — items near the 400 KB limit, or requests that read/write many attributes, take measurably longer to serialize and transfer than small items
Strongly consistent reads under load — ConsistentRead=true requests are inherently slower than eventually consistent reads and more sensitive to backend contention
Retry storms from throttling — when ConsumedReadCapacityUnits or ConsumedWriteCapacityUnits exceed provisioned limits, SDK-level retries with backoff inflate the client-observed portion of latency even though DynamoDB-side SuccessfulRequestLatency for each individual attempt may look normal
How the Nuberio Audit checks SuccessfulRequestLatency
The free Audit scans every Amazon DynamoDB resource in your account and checks whether a SuccessfulRequestLatency 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 SuccessfulRequestLatency alarms. Free, 5-minute read-only scan.
Related Amazon DynamoDB metrics
SuccessfulRequestLatency rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon DynamoDB coverage.
FAQ
Frequently asked questions about SuccessfulRequestLatency
Common questions about setting up CloudWatch alarms for SuccessfulRequestLatency in Amazon DynamoDB.
What is the recommended CloudWatch alarm threshold for SuccessfulRequestLatency?+
p99 SuccessfulRequestLatency for a given Operation sustained noticeably above that operation's own rolling baseline (e.g., 2–3x the typical p99 for 5+ minutes). AWS does not publish a specific alarm threshold for this metric — DynamoDB's own marketing describes single-digit-millisecond performance for simple operations as a general characteristic, not a per-table SLA (per aws.amazon.com/dynamodb). A relative, per-Operation baseline (Nuberio recommendation) is more reliable than a fixed millisecond cutoff, because expected latency varies significantly by operation type (GetItem vs. Query vs. Scan), item size, and whether DAX or strongly consistent reads are in use.
Which CloudWatch namespace does SuccessfulRequestLatency belong to?+
SuccessfulRequestLatency is published in the AWS/DynamoDB namespace with a unit of Milliseconds. 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 SuccessfulRequestLatency?+
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 SuccessfulRequestLatency alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a SuccessfulRequestLatency alarm set up?+
Yes. The free Audit works whether or not you have any SuccessfulRequestLatency 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, and DynamoDB. To find which Amazon DynamoDB alarms your account is missing — including SuccessfulRequestLatency — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.