5xx errors get all the attention because they're obviously the server's fault. But 4xx client errors are sneakier: they're labelled "the client's problem," so teams ignore them — right up until a spike of 403s turns out to be a broken auth deploy, or a flood of 404s reveals that your last release shipped with the wrong asset paths and Google is busy de-indexing your pages.
This guide explains the 4xx family from first principles: what each major status code means, what actually causes it, how 4xx differs from 5xx for monitoring, and which 4xx patterns should page you at 3am versus which are just background noise.
For the server side, see 5xx server errors explained. For the full status-code map, see HTTP status codes explained.
What "4xx" Actually Means
The HTTP spec divides status codes into classes by their first digit:
- 2xx — success.
- 3xx — redirection.
- 4xx — client error: the request was malformed, unauthorized, forbidden, or asked for something that isn't there.
- 5xx — server error: the request was fine, but the server failed to fulfil it.
The key word in "client error" is intent: 4xx means the server is telling the client "I understood you, and I'm refusing or unable to act on this as you asked it." That framing matters, because the "client" is often your own frontend, your mobile app, or a crawler — which makes many 4xx errors very much your problem to fix.
The 4xx Codes That Matter
400 Bad Request
The request is malformed — bad JSON, an invalid query parameter, a header the server can't parse. Generic catch-all when nothing more specific fits.
- Common real causes: a frontend serializing a payload wrong after a deploy, a missing required field, an oversized header, malformed multipart uploads.
- Watch for: a sudden 400 spike right after a release — almost always a client/server contract mismatch.
401 Unauthorized
Authentication is missing or invalid. (Despite the name, it's about authentication, not authorization.) The response should include a WWW-Authenticate header.
- Common real causes: expired tokens, a rotated signing key, a clock-skew issue invalidating JWTs, a misconfigured auth provider.
- Watch for: a fleet-wide 401 spike — usually a token/key rotation gone wrong or an identity-provider outage. See login & auth flow monitoring.
403 Forbidden
The server understood the request and knows who you are, but you're not allowed. Authentication succeeded; authorization failed.
- Common real causes: WAF rules blocking traffic, IP allow-lists, missing role/scope, S3/bucket permission errors, geo-blocking, bot mitigation.
- Watch for: 403s from legitimate users after a security-rule change, or a WAF false-positive wave. A 403 spike on assets can mean a CDN signing/permissions regression.
404 Not Found
The resource doesn't exist at that URL. The single most common 4xx — and the most dangerous for SEO.
- Common real causes: broken internal links, renamed routes without redirects, deleted pages, wrong asset paths after a build, deep links to removed content.
- Watch for: 404s on URLs that used to be 200 — that's a regression, not organic noise. 404s on JS/CSS/image assets mean a broken deploy. For redirect hygiene, see redirect chain monitoring.
SEO note: Soft 404s (a page that returns 200 but says "not found") are worse than honest 404s, because Google wastes crawl budget and may index junk. Validate the body, not just the status — see response body validation.
405 Method Not Allowed
The URL exists but the HTTP method doesn't (e.g. a POST to a GET-only endpoint). Usually a client bug or a missing route handler. The response should list allowed methods in the Allow header.
408 Request Timeout
The client took too long to send the complete request and the server gave up waiting. Often network/client-side, but can also indicate a misconfigured proxy or an under-resourced server closing slow connections.
409 Conflict
The request conflicts with the current state — classic in optimistic-locking, duplicate resource creation, or version mismatches. Expected in some APIs; a spike can mean a retry storm or a race condition.
410 Gone
Like 404, but intentional and permanent — "this used to exist and is deliberately removed." Better than 404 for SEO when you've truly retired a URL, because it tells search engines to drop it faster.
422 Unprocessable Entity
The syntax is valid but the semantics fail validation (e.g. a well-formed JSON body that violates business rules). Common in APIs using validation frameworks. A spike often signals a frontend validation gap.
429 Too Many Requests
The client is rate-limited. The response should include Retry-After. Critical to monitor because it sits on the boundary between protecting your service and breaking legitimate clients.
- Common real causes: an aggressive client/integration, a retry loop, a crawler, or a too-tight limit throttling real users.
- Watch for: 429s to legitimate traffic (a limit set too low), or a 429 surge that precedes a DDoS. Full detail in API rate-limit monitoring.
4xx vs 5xx: Why Monitoring Differs
| Aspect | 4xx (client error) | 5xx (server error) |
|---|---|---|
| Whose "fault" | The request (client, frontend, crawler, config) | The server/infrastructure |
| Healthy baseline | Non-zero — some 4xx is normal | Should be near zero |
| Alert model | Alert on anomalies and rate changes | Alert on any sustained presence |
| Typical fix | Client code, routing, auth, WAF, limits | Capacity, deploys, dependencies |
| SEO impact | High (404/410 affect indexing) | Moderate (prolonged 5xx hurts) |
The crucial difference: a healthy site always has some 4xx traffic. Bots probe random URLs, users mistype, old bookmarks rot, scanners hunt for /wp-admin. If you alert on "any 404," you'll drown in noise. 5xx is the opposite — a steady 5xx rate above ~0.1% is almost always worth investigating.
So 4xx monitoring is fundamentally about baselines and deltas, not absolute thresholds.
What To Monitor
1. 4xx rate as a share of traffic — by code
Track 400, 401, 403, 404, 429 as separate time series, each as a percentage of total requests. Blending them hides the signal — a 403 spike and a 404 spike have completely different root causes.
2. 4xx by route and by referer
A 404 rate that's flat globally but 100% on /pricing after a deploy is a regression. Segment by:
- Route/path — to localize a broken deploy.
- Referer — internal referers mean you are linking to dead URLs (fixable); external/no referer is often crawlers (mostly noise).
- User agent — separate real browsers from bots.
- Authenticated vs anonymous — a 401/403 spike among logged-in users is an incident.
3. The "was 200, now 4xx" signal
The highest-value 4xx alert. Maintain a set of known-good URLs (your top pages, key API endpoints, critical assets) and alert the moment any of them returns 4xx. This is exactly what synthetic checks are for — and it catches the broken-deploy case that rate-based alerts miss until traffic accumulates.
4. 429 against legitimate clients
Tag rate-limit rejections by whether the client is authenticated/known-good. 429s to real users mean your limits are mis-tuned, not that you're under attack.
Alerting That Won't Burn You Out
Because some 4xx is normal, alert on change, not presence:
| Severity | Trigger | Why |
|---|---|---|
| Critical | A known-good URL/endpoint returns any 4xx | Broken deploy or auth/permission regression |
| Critical | 401/403 rate among authenticated users jumps >5x baseline | Token rotation, IdP outage, WAF misfire |
| High | 404 rate on internal-referer requests rises sharply | You shipped dead internal links |
| High | 429 to authenticated/known clients appears | Rate limits throttling real traffic |
| Medium | Total 4xx share rises >2x the 7-day baseline | Something changed; investigate |
| Info | Anonymous/no-referer 404s rise | Usually crawler noise; digest only |
Anchor everything to a rolling baseline. For the philosophy behind this, see alert fatigue.
Common 4xx Incidents (And Their Tells)
- Bad deploy → 404 on assets: pages render unstyled, 404 rate on
.js/.cssspikes, internal-referer 404s jump. Roll back or fix asset paths. - Token/key rotation → 401 everywhere: authenticated traffic collapses to 401 fleet-wide within minutes of a deploy or cert rotation.
- WAF rule change → 403 wave: legitimate users (often from specific regions or networks) suddenly forbidden.
- Retry storm → 429 + 409: a client bug retries aggressively, tripping rate limits and creating conflicts.
- Renamed routes without redirects → 404 + lost rankings: organic traffic to specific URLs drops as Google sees 404s. Add 301s; use redirect monitoring.
- Soft 404 → silent SEO bleed: "not found" pages returning 200; only content validation catches it.
4xx and SEO: The Part Teams Forget
Search engines treat 4xx codes as signals:
- 404 / 410: the page is gone. 410 ("Gone") is processed faster as a permanent removal; 404 is treated as possibly-temporary. Use 410 when you mean it.
- 403 to Googlebot: if a WAF or bot rule accidentally forbids Googlebot, your pages stop being crawled — a silent de-indexing risk. Verify crawler access explicitly.
- Soft 404s: waste crawl budget and can get junk indexed.
- 429 to crawlers: rate-limiting Googlebot too hard slows indexing of new content.
Monitoring 4xx is therefore an SEO safeguard, not just an ops concern.
Quick Reference
- 4xx = the request was refused or couldn't be fulfilled as sent; the "client" is often your own frontend, app, or a crawler.
- 400 malformed · 401 not authenticated · 403 authenticated-but-forbidden · 404 not found · 405 wrong method · 408 client timeout · 409 conflict · 410 intentionally gone · 422 failed validation · 429 rate-limited.
- Some 4xx is always normal — alert on deltas and on known-good URLs turning 4xx, not on raw presence.
- Segment by code, route, referer, user agent, and auth status.
- 404/410/403 carry real SEO consequences — monitor them as such.
How Webalert Helps
Webalert catches the 4xx errors that matter — the ones hitting real, important URLs — from outside your infrastructure:
- Status-code checks on your key pages and API endpoints, alerting the instant a known-good URL returns 4xx.
- Content validation so soft 404s (200 OK but "not found") don't slip through — see response body validation.
- Multi-region checks to catch geo-specific 403s from WAF or bot rules — see multi-region monitoring.
- Crawler-path checks so an accidental 403/429 to search engines is caught before it costs rankings.
- Auth-flow monitoring to detect 401 waves from token/key rotation — see login & auth flow monitoring.
Example check tuned for 4xx safety:
- URL:
https://example.com/pricing - Expected status:
200(alert on any 4xx) - Must contain: a string you know is always on the page
- Regions: US + EU
- Frequency: 60s
Pair it with a check on a key API endpoint and your critical assets, and broken-deploy 4xx errors surface in seconds.
Summary
4xx errors are mislabelled. "Client error" makes them sound like someone else's problem, but the client is usually your own frontend, app, integration, or a search crawler — which makes 4xx very much yours to monitor. The discipline is different from 5xx: some 4xx is always normal, so you alert on baselines, deltas, and known-good URLs turning bad, segmenting by code, route, referer, and auth status. Do that, and a broken deploy, a botched key rotation, or an SEO-killing 404 wave shows up in seconds instead of in next month's traffic report.