CloudWatch Metric Guide
4xxErrorsAmazon S3 CloudWatch metric
4xxErrors reports HTTP 4xx client error status codes returned 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 4xxErrors
4xxErrors reports HTTP 4xx client error status codes returned 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 | 4xxErrors |
| Unit | Count |
| AWS docs | Official Amazon S3 metrics reference |
Why this metric matters
4xxErrors almost always points to an access or reference problem rather than an S3 outage: a 403 from an IAM or bucket policy change that unintentionally revoked access, a 404 because the application is requesting a key that was deleted or never existed, or a burst of 403s from clients retrying an expired presigned URL.
The important caveat AWS documentation makes clear: unlike BucketSizeBytes and NumberOfObjects, 4xxErrors is a request metric, not a storage metric. It does not appear in CloudWatch by default — you must explicitly enable request metrics on the bucket (a "metrics configuration," either for the entire bucket or filtered by prefix/tag), which carries an additional CloudWatch cost and only then starts publishing at roughly one-minute granularity. Plenty of buckets have zero visibility into this metric simply because no one opted in.
Recommended alarm threshold for 4xxErrors
Recommended threshold
Average (error rate) > 5% sustained for 5 minutes — or Sum-based, scaled to your normal request volume
AWS does not publish a universal 4xxErrors threshold — some 404s and 403s are expected background noise on any public or multi-client bucket. A 5% sustained error-rate threshold (Nuberio recommendation) is a starting point for distinguishing normal noise from a real access or reference regression; low-traffic buckets should alarm on the Sum statistic instead, since a percentage is noisy at low request volume.
Is your 4xxErrors alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including 4xxErrors — in 5 minutes.
Common failures that show up in 4xxErrors
When 4xxErrors reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
IAM or bucket policy change that unintentionally revoked access (403 Access Denied), often from a policy update or expired credentials
Application requesting objects that don't exist (404 NoSuchKey) after a deletion, migration, or key-naming change
Presigned URL expiration — clients retrying with an expired URL generate a burst of 403s
CORS misconfiguration blocking cross-origin browser requests
Client-side misconfiguration — wrong bucket name, region endpoint, or malformed request generating 400s
How the Nuberio Audit checks 4xxErrors
The free Audit scans every Amazon S3 resource in your account and checks whether a 4xxErrors 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 4xxErrors alarms. Free, 5-minute read-only scan.
Related Amazon S3 metrics
4xxErrors rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon S3 coverage.
FAQ
Frequently asked questions about 4xxErrors
Common questions about setting up CloudWatch alarms for 4xxErrors in Amazon S3.
What is the recommended CloudWatch alarm threshold for 4xxErrors?+
Average (error rate) > 5% sustained for 5 minutes — or Sum-based, scaled to your normal request volume. AWS does not publish a universal 4xxErrors threshold — some 404s and 403s are expected background noise on any public or multi-client bucket. A 5% sustained error-rate threshold (Nuberio recommendation) is a starting point for distinguishing normal noise from a real access or reference regression; low-traffic buckets should alarm on the Sum statistic instead, since a percentage is noisy at low request volume.
Which CloudWatch namespace does 4xxErrors belong to?+
4xxErrors 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 4xxErrors?+
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 4xxErrors alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a 4xxErrors alarm set up?+
Yes. The free Audit works whether or not you have any 4xxErrors 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 4xxErrors — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.