What is Apdex?
A 0–1 score that summarizes user satisfaction
Apdex (Application Performance Index) is a standardized metric that summarizes application performance from the user's perspective as a single number between 0 and 1. It was proposed in 2004 by an industry consortium of monitoring vendors to replace raw latency numbers with something an executive could read.
The core idea: every request falls into one of three buckets based on how long it took — Satisfied, Tolerating, or Frustrated — relative to a target response time T.
Satisfied: response time ≤ T. The user is happy.
Tolerating: T < response time ≤ 4T. The user notices the slowness but completes the task.
Frustrated: response time > 4T. The user is likely to abandon or complain.
The Apdex formula
How to compute Apdex from your request data
Apdex = (Satisfied count + 0.5 × Tolerating count) ÷ Total request count.
Example: Over 1 hour your API served 10,000 requests. 7,500 were satisfied (≤ T), 2,000 were tolerating (T to 4T), and 500 were frustrated (> 4T). Apdex = (7500 + 0.5 × 2000) ÷ 10000 = 8500 / 10000 = 0.85.
Frustrated requests contribute 0 to the score. Tolerating requests contribute half-weight. Satisfied requests contribute full weight. This asymmetry means a single frustrated user hurts your score more than a single tolerating user helps it — which matches psychology research on user satisfaction.
Apdex is always between 0 (everyone frustrated) and 1 (everyone satisfied). It has no units, which makes it comparable across services with different absolute latencies.
How to pick the right T (threshold)
The decision that determines whether Apdex is useful
T is the target response time for a satisfied user. Choose T based on the type of interaction and user expectation — not by measuring your current performance.
Industry conventions: Page load (user-facing): T = 1–2s. API call (programmatic): T = 300–500ms. Background job: T = depends on job type.
If T is too high, Apdex sits at 1.0 permanently and you lose signal. If T is too low, Apdex sits at 0.3 permanently and the number is meaningless. Both are tuning failures.
Different transactions deserve different T values. The checkout page is slow if it takes > 2s; a healthcheck endpoint is slow if it takes > 50ms. Set T per transaction type or per route.
Document the T values you choose and the reasoning. "T = 500ms because our competitor P95 is 400ms and we want to stay competitive" is a defensible choice; "T = 500ms because that's what the APM tool defaulted to" is not.
Apdex grading scale
What score counts as good
0.94 – 1.00: Excellent. Users are consistently satisfied.
0.85 – 0.93: Good. Most users are satisfied; some notice slowness.
0.70 – 0.84: Fair. Significant portion of users experience slowness.
0.50 – 0.69: Poor. Many users frustrated.
0.00 – 0.49: Unacceptable. Service is broken from the user's perspective.
For revenue-affecting services, teams typically target Apdex ≥ 0.9 and alert when it drops below 0.85 for more than 5 minutes.
Apdex vs latency percentiles
When to use which
Latency percentiles (p50, p95, p99) tell you the shape of your latency distribution. p99 = 2.3s means 1% of requests took longer than 2.3s. Essential for engineering diagnostics.
Apdex tells you how many users were satisfied. It compresses the whole distribution into one business-readable number.
Use latency percentiles for engineering investigation ("why did p99 jump at 3pm?"). Use Apdex for executive reporting and SLO definition ("maintain Apdex ≥ 0.9").
Modern APM tools show both side by side. Apdex is a reasonable default for alerting because it reflects user-visible impact; a p95 alert fires on 5% of requests, but you may not know whether those 5% matter.
Common Apdex mistakes
Pitfalls that make your Apdex score lie
Ignoring errors: Apdex typically counts failed requests (5xx, exceptions) as frustrated. If your APM is excluding errors, your score is artificially high.
One T for everything: a global T of 500ms for a service that serves both a healthcheck (should be < 50ms) and a report-generation endpoint (acceptable at 5s) is useless.
Averaging Apdex across time: Apdex is already an average over the time window. Averaging the averages biases the result. Compute Apdex over the raw request data for the time range you want.
Not segmenting by cohort: an aggregate Apdex of 0.92 can hide an Apdex of 0.5 for mobile users on 3G. Break out Apdex by device, geography, user tier.
Treating Apdex as a universal truth: it is a convention. If your users expect sub-100ms response for every interaction (e.g., a trading app), the Apdex scale needs recalibration.
Key Takeaways
- Apdex = (Satisfied + 0.5 × Tolerating) ÷ Total requests. Range: 0–1.
- Choose T based on user expectation, not current performance; tune per transaction type.
- Satisfied ≤ T, Tolerating ≤ 4T, Frustrated > 4T. Errors count as frustrated.
- Target Apdex ≥ 0.9 for revenue services; alert below 0.85.
- Use Apdex for executive/SLO reporting; use latency percentiles for engineering investigation.
- Segment Apdex by cohort (device, geo, user tier) to catch issues the aggregate hides.