At a glance
The 95th-percentile response time across server-side Transaction events. The “tail latency” number that captures the experience of the worst-served 5% of customers. Average latency lies; p95 tells you whether your slowest checkouts are still acceptable.
Calculation
Calculated automatically from your New Relic data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A Shopify Plus storefront on a Node.js BFF (backend-for-frontend) layer. The Apdext is configured to 0.5s for browse pages, 1.0s for checkout. The 5-minute window covers 09:00, 09:05 on 02 May 26.
The mean of 380ms looks fine, but p95 reveals that 5% of customers (about 600 of every 12,000 in a 5-minute window) are waiting nearly 2 seconds for a server response, before any browser parsing or network transit. With Apdex
t = 0.5, the frustrated threshold is 4 x 0.5 = 2.0s, so this group is sitting right on the frustrated boundary. Apdex of 0.74 confirms that a meaningful chunk has already crossed it.
Conversion impact. Akamai 2017 and Deloitte 2020 data converge on roughly 7% conversion drop per 100ms of additional p95 latency on commerce checkouts. From a healthy 1,000ms baseline to 1,840ms is +840ms, mapping to a ~58% conversion drop on the affected slice. On a £2M/month checkout flow with 5% of visitors in the slow-tail group, the exposure is roughly £2M x 5% x 58% = £58k/month of risked conversion. The exposure ends the moment p95 returns to baseline.
Apdex calibration interaction. Apdex with t = 0.5 rewards fast servers heavily. Below 0.5 means most users are frustrated; the formula puts you there if more than half your traffic is over 2s. So Apdex going from 0.86 to 0.5 typically corresponds to p95 going from 1.0s to roughly 2.5, 3.0s on a real distribution.
If next 5-minute window’s p95 climbs to 2,400ms (still common on a hot evening or during a deploy), the conversion impact roughly doubles, the frustrated bucket expands from 5% to 12, 15% of traffic, and Apdex drops below 0.6. At that point this card alone justifies pulling the deploy or rolling back.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic:- APM > Application > Summary shows the response-time chart with selectable percentiles.
- Dashboards > “Latency analysis” pre-built.
- Service Levels if a latency SLO is configured.
- Alerts & AI > Conditions for the alert backing this card.
Cross-connector reconciliation:
NR APM agent and Datadog APM trace agent instrument at slightly different points in the request lifecycle. NR typically measures from the framework middleware entry to response finish; Datadog often includes a few hundred microseconds of trace-collection overhead. Steady-state p95 numbers should agree within 5, 15ms. A 30ms+ persistent gap is itself diagnostic, not noise. The most common causes: (a) one platform missing the framework’s pre-routing middleware (auth, CORS); (b) one agent’s sampling cutoff different (NR samples >100ms requests at higher rate by default); (c) different
appName / service filter scope.
NR Browser RUM and GA4 Web Vitals also disagree on Browser p95 latency: Browser RUM instruments every page load, GA4 samples by session. On stores with low session rates (B2B), the GA4 number can be 15, 25% noisier than RUM.
Known limitations / merchant FAQs
NR vs Datadog: which one’s p95 should I trust? Both, on different scopes. If the two agree within 15ms, neither is wrong, both are valid samples of the same underlying distribution. If the gap is larger and persistent, audit instrumentation coverage on each platform; the discrepancy almost always traces to one platform missing a route or a middleware. We’ve seen NR run 8ms higher than DD on Express.js apps (because NR includes the route-matching middleware DD skips), and 12ms lower on Spring Boot (because DD’s interceptor sits earlier in the chain). Apdex math: how does p95 relate to Apdex? They measure overlapping but distinct things. Apdex witht = 0.5s puts everything above 2s (4 x t) in the frustrated bucket. So p95 going from 1s to 2.5s typically drops Apdex from ~0.85 to ~0.55 because the frustrated bucket roughly doubles. p95 is the raw number; Apdex is the satisfaction-weighted reading. Both should be on your wall.
NRQL retention: can I see p95 over 90 days?
Yes, but on aggregated data past day 8 (standard plan) or day 395 (Data Plus). The p95 number remains valid; what you lose is the ability to drill into a specific 5-minute window past the retention boundary. For 90-day trend analysis use the rolled aggregates; for incident forensics stay within the full-resolution window.
Why does my p95 disagree with Datadog by 12ms?
Probe-overhead difference. Both are right; the gap is a known constant for your stack and as long as it stays constant, trends match across platforms. If a deploy lands and NR shows +50ms while DD shows the same +50ms, the regression is real on both. The 12ms baseline gap is not a problem; a sudden change in the gap (NR +50, DD +5) would be.
Sampling impact on p95: am I missing slow requests?
No. NR’s t-digest percentile algorithm is designed to be sample-stable. Even at 25% sampling, p95 estimates are within ~10ms of true on most production distributions (Akamai 2018 study). What sampling does affect is the count of slow requests, not the percentile threshold. If you need exact slow-request counts (for SLA enforcement), use raw event count alongside the percentile.
Multi-account: my US and EU accounts have different p95 baselines, how do I monitor both?
Connect each NR account as a separate Vortex IQ integration and stack the cards in the Nerve Centre. Stack panels handle weighted aggregation correctly, the combined p95 is computed by merging t-digest sketches, not by averaging the two p95s (which would be mathematically wrong).
Ingest cost vs visibility: can I save money without losing p95 accuracy?
Yes. Drop sample rate on non-checkout transactions to 25%, keep checkout at 100%, keep all error events at 100%. The p95 estimate stays sample-stable, error rate stays accurate, and ingest cost typically drops 40, 60%. This is the standard Vortex IQ recommended config.
Alert tuning: my p95 alert flutters at 1500ms during peak traffic, what should I tune?
Three options in order: (a) raise the threshold to 1750ms if your peak baseline is reliably 1400, 1500ms; (b) add a 5-minute “must stay above 1500ms” duration clause; (c) split the alert into two: a peak-traffic alert (12:00, 21:00) at 1750ms and an off-peak alert at 1200ms. Option (c) is most accurate for stores with strong diurnal traffic patterns.
My p99 is 8s but p95 is 800ms, is that OK?
A 10x gap between p95 and p99 means you have a long tail. Usually one of: a slow background job competing for shared resources, a cold-cache penalty on the first request to a region, or a single overloaded host. Open p99 Latency faceted by host to see if the slow tail is concentrated.