CloudWatch Metric Guide
5xxErrorsAmazon S3 CloudWatch metric
5xxErrors reports HTTP 5xx server error status codes returned by S3 for requests to a bucket, published as 0 or 1 per request. The Sum statistic gives the error count for the period; the Average statistic gives the error rate.
What it measures
About 5xxErrors
5xxErrors reports HTTP 5xx server error status codes returned by S3 for requests to a bucket, published as 0 or 1 per request. The Sum statistic gives the error count for the period; the Average statistic gives the error rate.
| Namespace | AWS/S3 |
| Metric name | 5xxErrors |
| Unit | Count |
| AWS docs | Official Amazon S3 metrics reference |
Why this metric matters
5xxErrors reflects problems on S3's side rather than your application's: a 503 SlowDown response when request volume against a bucket (or more specifically a narrow key-prefix range) exceeds what that partition can currently handle, or an occasional 500 Internal Error, which AWS's own SDKs already retry with exponential backoff. A sustained rise in 5xxErrors is a real signal — it usually means your access pattern is hitting a request-rate hot spot, most commonly from sequential or timestamp-prefixed key naming that concentrates traffic on one partition instead of spreading it.
The same opt-in caveat as 4xxErrors applies here: 5xxErrors is a request metric that only exists in CloudWatch once you explicitly enable request metrics on the bucket (an additional cost, at roughly one-minute granularity), unlike the always-on, free BucketSizeBytes and NumberOfObjects storage metrics.
Recommended alarm threshold for 5xxErrors
Recommended threshold
Average (error rate) > 1% sustained for 5 minutes — or Sum > 0 sustained across periods for low-traffic buckets
AWS documentation frames 5xx responses as rare under normal operation, and recommends client-side retry with backoff rather than a published numeric threshold. A low, sustained-rate threshold (Nuberio recommendation) distinguishes the occasional expected 500/503 blip from a genuine request-rate hot-partition problem that needs a key-naming or access-pattern fix.
Is your 5xxErrors alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including 5xxErrors — in 5 minutes.
Common failures that show up in 5xxErrors
When 5xxErrors reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Request rate exceeding what a single key prefix can scale to, producing 503 SlowDown errors — commonly caused by sequential or timestamp-prefixed object keys
Transient internal S3 service errors (500 Internal Error), which AWS recommends handling with client-side retry and exponential backoff
A sudden traffic spike (flash crowd) arriving faster than S3 can automatically scale request partitions for that prefix
A high-volume parallel multipart upload or PUT pattern concentrated on a narrow key range
A proxy, CDN, or Object Lambda layer in front of the bucket surfacing S3-side 5xx responses during a regional service event
How the Nuberio Audit checks 5xxErrors
The free Audit scans every Amazon S3 resource in your account and checks whether a 5xxErrors 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 5xxErrors alarms. Free, 5-minute read-only scan.
Related Amazon S3 metrics
5xxErrors rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon S3 coverage.
FAQ
Frequently asked questions about 5xxErrors
Common questions about setting up CloudWatch alarms for 5xxErrors in Amazon S3.
What is the recommended CloudWatch alarm threshold for 5xxErrors?+
Average (error rate) > 1% sustained for 5 minutes — or Sum > 0 sustained across periods for low-traffic buckets. AWS documentation frames 5xx responses as rare under normal operation, and recommends client-side retry with backoff rather than a published numeric threshold. A low, sustained-rate threshold (Nuberio recommendation) distinguishes the occasional expected 500/503 blip from a genuine request-rate hot-partition problem that needs a key-naming or access-pattern fix.
Which CloudWatch namespace does 5xxErrors belong to?+
5xxErrors is published in the AWS/S3 namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/S3". See the Amazon S3 CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for 5xxErrors?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon S3 resources are missing a 5xxErrors alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a 5xxErrors alarm set up?+
Yes. The free Audit works whether or not you have any 5xxErrors 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 S3 alarms your account is missing — including 5xxErrors — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.