Error Rate Calculator
Calculate error rate and success rate from request counts, and see the equivalent reliability in “nines”.
Formula last reviewed 4 August 2026 · How we verify our calculators
Error rate
- Success rate
- 99.5%
- Failed requests
- 250
- Roughly equivalent to
- ≈ 99.500% (between table bands)
Updates live as you type
Frequently asked questions
Error rate = failed requests ÷ total requests × 100. 250 failures out of 50,000 requests is a 0.5% error rate, or 99.5% success.
It is shorthand for an availability percentage: “three nines” is 99.9%, “four nines” is 99.99%. Each extra nine cuts allowed failure roughly tenfold.
A request-success rate is the most common availability SLI. Measured over your SLO window and compared to the target, this same number becomes your SLI.
Typically HTTP 5xx (and sometimes specific 4xx) count as failures, while 2xx/3xx count as successes. Define the exact set for your service so the rate is meaningful.
Your error budget is the total failures allowed by your SLO; the error rate tells you how quickly you’re spending it. A sustained error rate above your budget pace will exhaust it early.
Two hundred and fifty failures in fifty thousand
Of 50,000 requests, 250 failed. That is an error rate of 0.5% and a success rate of 99.5% — which, expressed in the reliability shorthand, sits between two nines and three nines.
Error rate is the simplest reliability measure there is, and the one every other measure on this site is built from. Its value lies in being immediately comparable across services, time periods and traffic volumes in a way that a raw count of failures is not.
The calculation
Error rate (%) = failed requests ÷ total requests × 100 Success rate (%) = 100 − error rate
250 ÷ 50,000 = 0.005, so 0.5% error and 99.5% success.
The nines, and where this sits
Success rates are conventionally described by how many leading nines they carry:
- 99% — two nines, 1 failure in 100
- 99.9% — three nines, 1 in 1,000
- 99.99% — four nines, 1 in 10,000
- 99.999% — five nines, 1 in 100,000
A 99.5% success rate falls between two and three nines. Each additional nine means ten times fewer failures, which is why moving from 99.9% to 99.99% is a genuinely different engineering problem rather than an incremental improvement.
What counts as a failure
The arithmetic is trivial; the classification is where judgement is required, and where two teams measuring "the same" service can legitimately produce different numbers.
5xx responses are almost universally counted — the server failed.
4xx responses are contested. A 404 for a URL a user mistyped is not your service failing. A 400 caused by your own client sending a malformed request arguably is. A 429 from your rate limiter is a deliberate rejection, and whether it counts depends on whether the limit is protecting you from abuse or throttling legitimate users.
Timeouts and connection failures often never reach your server at all, so they are missing from server-side logs entirely. This is the single largest blind spot in error-rate measurement — a service can report 99.99% from its own logs while a meaningful share of users cannot connect. Measuring at the client or at an external probe catches what server logs cannot.
Slow-but-successful responses count as successes here, which for many services understates the real user experience. Defining the SLI as "successful within a latency threshold" is usually closer to what users care about.
Reading the result
A single error rate over a long period hides distribution. A 0.5% rate could mean a uniform trickle, or ten minutes of total outage in an otherwise perfect month. The second is far more damaging to users and far more actionable, and averaging conceals it.
Two refinements worth adopting: measure error rate in short buckets (per minute or per five minutes) and look at the worst buckets rather than the mean; and weight by user rather than request, since one user retrying a failing action fifty times generates fifty errors but represents one broken experience.
Also note that error rate is volume-blind in the other direction: 0.5% of 50,000 is 250 affected requests, while 0.5% of 50 million is 250,000. The percentage is identical and the human impact is not.
Common mistakes
Measuring only server-side. Failures that never reach the server are invisible.
Averaging over long windows. It smooths away exactly the spikes worth investigating.
Counting all 4xx as failures, or none. Decide deliberately and document it.
Ignoring partial failures. A page that renders with one broken widget is a success by HTTP status and a degraded experience in fact.
Comparing error rates across services with different definitions. Without a shared definition of failure the comparison is meaningless.