Last updated: 2026-07-02

Apdex Score

Apdex — the Application Performance Index — is an open standard for turning a stream of response-time measurements into a single satisfaction score between 0 and 1. It was designed so that application performance can be reported to non-specialists without a chart: one number captures the proportion of requests that were fast enough to keep users happy. Apdex is widely supported by monitoring platforms and is a common way to express a response-time service-level objective.

Formula

Every request is compared against a target threshold $T$ and sorted into one of three buckets:

• Satisfied — response time at or below $T$.
• Tolerating — response time greater than $T$ but at or below $4T$.
• Frustrated — response time greater than $4T$, or the request failed or timed out.

The score is the number of satisfied samples plus half the tolerating samples, divided by the total number of samples:

where the total is the sum of all three counts:

Tolerating requests count as half because those users noticed the delay but were not blocked. Frustrated requests contribute nothing. The result always lies between 0 (every request frustrated) and 1 (every request satisfied). The threshold $T$ determines which bucket each request lands in, but it does not appear in the arithmetic once the counts are fixed.

Worked Example

Suppose a monitoring window of 1,000 requests, measured against a threshold of $T = 500$ ms, breaks down as follows:

• 850 requests were satisfied (≤ 500 ms)
• 120 requests were tolerating (500 ms – 2,000 ms)
• 30 requests were frustrated (> 2,000 ms or failed)

First, confirm the total:

Then apply the formula:

A score of 0.910 falls in the "good" band, indicating that response times met users' expectations for most of the traffic in this window.

Rating Bands

The Apdex Alliance publishes qualitative labels so a bare number can be communicated at a glance. A widely used mapping is:

These bands are a reporting convention rather than a strict specification. A team with aggressive latency goals may treat anything below 0.94 as needing attention, while a batch-oriented back-office system might set a more relaxed bar.

Choosing the Threshold

The single most consequential decision is the value of $T$. Set it too high and a sluggish application will still report a flattering score; set it too low and even a healthy service looks poor. The specification recommends anchoring $T$ to the response time users perceive as the edge of a smooth experience, or to the target in an existing service-level objective — often in the range of a few hundred milliseconds for interactive pages. Because the frustrated boundary is fixed at $4T$, choosing $T$ automatically fixes the whole bucketing scheme.

Limitations

Apdex compresses a full latency distribution into one number, so it necessarily discards detail. Two very different distributions can share the same score, and the fixed $4T$ tolerating boundary may not match how a specific application's users actually experience delay. The score also says nothing about throughput, error semantics beyond the frustrated bucket, or which requests were slow. Treat it as a high-level satisfaction indicator, and pair it with percentile latency and error-rate metrics when diagnosing a regression.

For a related view of availability targets, see Uptime SLA Calculator.