Elevated Client Error Rate (4xx)
API requests returning 4xx client errors — authentication failures, bad requests, or missing resources.
What this means
A high 4xx error rate tells you that a significant portion of incoming requests are being rejected before they ever reach your backend logic. In API Gateway, 4xx responses cover a wide range of client-side problems: 400 (Bad Request) from failed request validation, 401 (Unauthorized) from missing or invalid authentication tokens, 403 (Forbidden) from API key or IAM policy denials, 404 (Not Found) from requests to undefined routes, and 429 (Too Many Requests) from throttling. While each individual 4xx is arguably the caller's fault, a consistently elevated rate usually points to a systemic issue on your side -- a recently changed auth configuration, a deprecated endpoint that clients still call, or request validation rules that are too strict for real-world payloads.
The distinction between "normal" and "problematic" 4xx rates depends heavily on your API's nature. A public API that handles bot traffic or unauthenticated discovery requests might naturally see 5-10% 4xx responses. But a private microservice API where every caller is a known internal service should see almost zero client errors. When the 4xx rate spikes unexpectedly, it typically correlates with a deployment: a new request model validation that rejects previously-accepted payloads, a Cognito user pool configuration change that invalidates tokens, or an API key rotation that hasn't propagated to all consumers.
The cost of high 4xx rates extends beyond failed requests. Every rejected request still consumes API Gateway capacity, counts against your account-level throttle limits, and generates CloudWatch metrics that can obscure real availability problems. If 30% of your traffic is 4xx noise, your dashboards and alarms become unreliable. Cleaning up the 4xx rate makes your monitoring signal stronger and your error budgets meaningful.
Detection criteria
More than 25% of total requests return 4xx status codes.
More than 10% of total requests return 4xx status codes.
Example finding
31.2% of API Gateway requests returned 4xx errors (4,680 of 15,000 requests). Breakdown: 403 Forbidden (2,891), 400 Bad Request (1,204), 404 Not Found (585).
Recommendation: Review API request validation rules and model schemas. Check authentication/authorization configuration. The high 403 count suggests API key or IAM policy misconfiguration.
How to fix
Break down 4xx errors by status code
Not all 4xx errors are created equal. Start by segmenting your error logs by the specific status code. A high 403 rate points to authorization problems (API keys, IAM policies, resource policies, or WAF rules). A high 400 rate means request validation is rejecting payloads. A high 404 rate means clients are calling routes that do not exist. Each sub-category has a completely different fix, so the first step is always to identify which status code dominates the error rate.
Review request validation models
If 400 errors dominate, check your API Gateway request validators and JSON Schema models. A common pitfall is deploying a new model that requires a field your existing clients do not send. Review the requestValidation settings in your API definition. Consider making new fields optional with defaults during a migration period, and use Gateway response customization to return descriptive error messages so clients can self-diagnose.
Audit authorization configuration
For 401 and 403 errors, verify your authorizer setup. If using a Cognito authorizer, confirm the user pool ID and app client IDs match. If using a Lambda authorizer, check that it returns a properly formatted IAM policy document and that the resource ARN patterns match the actual API resource paths. Also verify that your API key usage plan is associated with the correct API stage and that clients are sending the key in the x-api-key header.
Add or fix CORS configuration
A surprising number of 4xx errors come from CORS preflight failures. If browser clients get 403 on OPTIONS requests, the API Gateway CORS configuration is missing or incomplete. For REST APIs, ensure the OPTIONS method returns proper Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers headers. For HTTP APIs, use the built-in CORS configuration in the API settings.
Clean up deprecated routes
If 404 errors are significant, clients are hitting routes that no longer exist. Rather than leaving them as 404s, create explicit routes that return 301 redirects or informative 410 (Gone) responses pointing to the replacement endpoints. This helps clients migrate and eliminates noise from your error metrics. Check your access logs to identify which deprecated paths are still receiving traffic and prioritize those for redirect rules.
Related patterns
- API Throttling Detected (429) — 429 responses are a subset of 4xx that indicate rate limiting
- High Server Error Rate (5xx) — server-side errors that may co-occur with client errors
Spot 4xx spikes in your API Gateway logs — upload a CloudWatch export to smplogs.
Try it free