Apdex (Application Performance Index) is an open standard that turns response times into a single satisfaction score between 0 and 1. Each request is classified as satisfied (at or below a threshold T), tolerating (above T, up to 4T) or frustrated (above 4T), and the score is (satisfied + tolerating / 2) / total.
What Apdex is
Apdex, short for Application Performance Index, is an open standard for reporting how satisfied users are with the responsiveness of an application. Instead of showing a latency histogram or a list of percentiles, Apdex reduces all measured response times in a time window to a single number between 0 (every user frustrated) and 1 (every user satisfied). The standard was published by the Apdex Alliance in the mid-2000s and has since been built into many APM tools.
The idea is simple: for each application or transaction you define one target response time, the threshold T. Everything else follows from that one number.
The Apdex formula
Every sample, usually a request or a page load, falls into one of three zones:
- Satisfied: response time ≤ T.
- Tolerating: response time > T and ≤ 4T.
- Frustrated: response time > 4T.
The score is then:
Apdex_T = (satisfied + tolerating / 2) / total samplesSatisfied samples count fully, tolerating samples count half and frustrated samples count zero. The result is commonly written with the threshold as a subscript, for example 0.91 [0.5] for a score of 0.91 at T = 0.5 seconds. Most tools also count failed requests as frustrated regardless of their duration, because a fast error is not a good experience. Check how your tool handles this before comparing scores across systems.
The Apdex specification suggests rating bands: 0.94 to 1.00 excellent, 0.85 to 0.93 good, 0.70 to 0.84 fair, 0.50 to 0.69 poor and below 0.50 unacceptable. Treat them as a starting point, not as a contract.
Example calculation
An illustrative checkout API has T = 300 ms, so the frustration boundary 4T is 1.2 s. In one five-minute window it handles 10,000 requests:
| Zone | Rule | Requests | Weight |
|---|---|---|---|
| Satisfied | ≤ 300 ms | 8,800 | 1 |
| Tolerating | 300 ms to 1.2 s | 900 | 0.5 |
| Frustrated | > 1.2 s or error | 300 | 0 |
Apdex = (8,800 + 900 / 2) / 10,000 = 9,250 / 10,000 = 0.925, which is "good" in the standard bands. Note what the number hides: the 300 frustrated requests could be timeouts on one payment provider, or a slow tail spread evenly across all users. You still need traces and latency distributions to tell the two apart.
How to choose the threshold T
T is the most important decision and also the most frequently neglected one. Many tools ship with a default such as 0.5 seconds, which is meaningless for a 20 ms internal API and too strict for a report export. Good practice is:
- Set T per transaction type. Search, checkout and file upload have different user expectations.
- Base T on user expectations, not current performance. If you pick T from today's median, the score only tells you that nothing changed.
- Use real user data for front ends. For pages, measure in the browser with real user monitoring, since server time is only part of what the user waits for.
- Keep T stable. Changing T resets the meaning of every historical score.
Apdex versus percentiles and SLOs
Apdex is easy to communicate, but it compresses information. Two very different distributions can produce the same score, and the fixed 4T rule does not distinguish between a request that took 1.3 s and one that took 30 s. That is why most SRE teams today prefer latency SLOs such as "99% of checkout requests complete in under 400 ms over 28 days". An SLO also defines a time window and an error budget, which makes it actionable for release decisions. Apdex remains useful as a quick, normalized health indicator on a dashboard and for comparing transactions with different thresholds side by side.
Common mistakes
- Keeping one global default T for every service.
- Averaging Apdex scores of services with very different traffic, which over-weights low-volume endpoints.
- Ignoring errors, so a service that fails fast looks perfectly satisfied.
- Alerting on small dips in low-traffic windows, where a handful of slow requests swings the score.
How Obseria helps
Obseria stores spans and RUM events in Obseria Lake with schema-on-read, so satisfied, tolerating and frustrated counts can be derived from the raw durations of any service or page, and you can recalculate with a different threshold later. Alongside such scores, Obseria provides percentiles, error rates and SLOs with error budgets, which are included in every plan.