Error rate
Error rate is the proportion of requests, page loads, or interactions that fail over a period. It comes in several flavors — server-side HTTP error rate (5xx/4xx share), client-side JavaScript error rate, and failed-interaction rate — each with its own numerator and denominator. As a RUM and reliability metric it signals broken experiences, but only when the failure definition and base are stated clearly.
What this means
Error rate divides failed events by total events. Server-side, that is often the share of responses with 5xx (and sometimes 4xx) status codes; client-side, it is the share of page loads or interactions that throw an unhandled JavaScript error or fail a network call. GA4 has an exception event for logging client errors. The numerator and denominator must match — counting backend failures against frontend loads mixes incompatible bases.
Choosing numerator and denominator
Whether 4xx counts as an error matters: a 404 for a mistyped URL is a different signal from a 500 server fault. Likewise, a JavaScript error rate per session differs from one per pageview. State the failure definition and the base explicitly, and segment by route, browser, and release so a spike can be localized. An error rate without these qualifiers is ambiguous and easy to misread.
Read error rate alongside crash-free users and RUM timings for a fuller reliability picture.
- HTTP error rate: 5xx (and optionally 4xx) share of responses
- JS error rate: unhandled errors ÷ loads or sessions
- State the failure definition and the denominator
How it appears in analytics and logs
A rising error rate flags broken functionality, but the flavor tells you where: an HTTP 5xx spike points to the backend, a JavaScript error spike to client code or a third-party script, and a failed-interaction spike to UX or API integration.
Diagnostic use case
Quantify how often something breaks for users, separating server failures, script errors, and failed actions so reliability work targets the right layer.
What WebmasterID can help detect
WebmasterID's observability surface captures error and exception signals first-party, so client-side error rate can be tracked without third-party monitoring scripts.
Common mistakes
- Mixing backend failures with frontend loads in one rate.
- Lumping 4xx and 5xx together without saying so.
- Logging PII-bearing URLs in error reports.
Privacy and accuracy notes
Error rate is an aggregate ratio. Error logs and stack traces must be scrubbed of URLs and fields containing personal data. This is educational, not legal advice.
Related pages
- Crash-free users rate
Crash-free users rate is the percentage of active users who used an app over a period without hitting a crash. It is a mobile stability metric, distinct from crash-free sessions, which counts at the session level. Because one user can have many sessions, the two rates differ: a single crashing user can drag the user-based rate while barely moving the session-based one.
- Real user monitoring (RUM) metrics
Real user monitoring (RUM) measures web performance from actual visitors' browsers in the field, as opposed to synthetic lab testing in a controlled environment. Its headline metrics are the Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — collected via the browser's performance APIs. Field data reflects real devices and networks, so it varies far more than lab numbers.
- The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
- Website observability
Track client-side errors first-party.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.