Latency on the checkout APM app overlaid with order volume, when checkout slows, sales follow.
At a glance
A dual-axis chart that overlays the checkout APM app’s p95 latency against the merchant’s order volume per minute over a rolling 24-hour window. The visual answer to “does my checkout latency move sales?” calibrated to the merchant’s actual conversion sensitivity.
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 BigCommerce store running on Cloud Run, NR APM oncheckout-api. The chart over a 4-hour window covering peak time (16:00, 20:00) on 02 May 26:
Reading the chart. The visual is two lines on the same time axis. When latency climbs, orders fall, with a 2, 5 minute lag (customers in flight when latency spikes complete; customers arriving after the spike abandon). The lag duration is the conversion-sensitivity coefficient for this store; in this example, every additional second of p95 latency above 1s costs roughly 1.8 orders/min. Multiplied by AOV of £92, that’s £165/min of conversion impact per second of additional latency.
Conversion impact translation. During the 30-minute sustained-3.4s window (17:25, 17:55), the order count averaged 2.1/min vs an expected 8.5/min. Lost orders:
(8.5 - 2.1) x 30 min = 192 lost orders. At £92 AOV, that’s £17,664 of GMV impact in 30 minutes, or roughly £35,000/hour run-rate. Plus the recovery-phase customers who don’t come back (typical 25% irrecoverable rate adds another ~£4,400 of permanent loss).
Apdex calibration interaction. With the checkout app’s Apdex t = 1.0s, the frustrated threshold is 4 x 1.0 = 4.0s. p95 of 3.4s sits at the boundary of tolerated (1.0s, 4.0s) but the right-tail (worst 5% beyond p95) is well into frustrated. Apdex during the sustained window dropped from 0.81 to 0.42, well below the satisfaction-healthy band. The composite Operational Health Score drops from 86 to 51, breaching the 70 alert threshold ~3 minutes before this card’s peak-hour alert fires.
Why the visual matters more than either number alone. A merchant looking at p95 = 3.4s in isolation sees “checkout is slow”. A merchant looking at orders = 2.1/min in isolation sees “sales are down”. The dual-axis chart makes the causal link visible and quantitative, the duty engineer can see exactly when latency moved and exactly when orders responded, and the slope of the relationship gives the conversion sensitivity for this specific store on this specific day.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic: NR doesn’t surface a single chart that overlays APM latency with order volume. The closest equivalents:- APM > Service > Summary for the latency timeseries.
- Dashboards > custom dashboard combining a NRQL chart for latency with a NRQL chart for
Orderevents (if the merchant pipes orders into NR via Custom Events). - For order volume, the merchant’s commerce platform’s live dashboard (Shopify Admin > Live View, BigCommerce > Reports).
Cross-connector reconciliation:
NR APM and Datadog APM should produce equivalent latency series within 5, 15ms (probe overhead difference). Both pull from the same commerce sibling for the order axis. The dual-axis charts on each platform should look essentially identical; if they don’t, the latency lines diverge first (probe coverage difference) and the order lines should always match exactly.
NR APM latency vs RUM page-load latency: APM is server-only; RUM includes network and browser. The two series should differ by 800, 1500ms on most stores (the network + browser overhead). When this card’s latency axis stays flat but RUM rises, the issue is client-side (CDN, third-party scripts) and the server-side checkout app is healthy.
Known limitations / merchant FAQs
NR vs Datadog: which is better for this kind of cross-platform chart? Either works equally well. The choice usually comes down to which platform owns the checkout APM instrumentation. If your team has spent two years building NR dashboards and runbooks, stay with NR; the cross-platform chart joins the same data either way. Apdex math: why isn’t Apdex on this chart? Apdex is a satisfaction-weighted derivative of latency, not an independent signal. Putting both Apdex and p95 on the same chart adds noise without insight, they move together by definition. The dual-axis design uses raw latency (most actionable) on one side and orders (most consequential) on the other, which is the most useful pairing for triage. NRQL retention vs window length: can I see this chart over 7 days? Yes. The default 24-hour window stays in the full-resolution NRQL retention; 7-day windows use rolled aggregates with slightly coarser percentile precision but still readable. For 30-day longitudinal analysis use the rolled aggregates; the visual correlation pattern is preserved. NR and Datadog disagree on the latency line by 12ms during peak, who’s right? Both. The 12ms gap is probe-overhead difference (NR APM agent vs DD trace agent instrumenting at slightly different points). The order line should match exactly because both pull from the same commerce sibling. As long as the shape of the latency line matches across both platforms, neither is wrong; only the absolute baseline differs. Sampling: does sampling affect this chart? The latency axis uses t-digest percentile which is sample-stable (~5ms accuracy at 50% sampling). The order axis is unsampled. So the chart stays accurate even on heavily-sampled NR accounts. Multi-account: can I overlay multiple checkout apps on one chart? Currently one app per card. Connect each checkout app as a separate integration and stack the cards in the Nerve Centre to compare. A future “multi-app” version is on the roadmap; for now the simplest workaround is to use NR’s native dashboard with a multi-app NRQLFACET appName.
Ingest cost vs visibility: can I reduce APM sampling without losing this chart?
Yes. Drop sample rate on the checkout app to 50% and the t-digest percentile stays accurate. Going below 25% starts to show flutter on the latency line during low-traffic minutes. Order data is unaffected by NR ingest configuration.
Alert tuning playbook: my peak-hour alert fires every Black Friday at 18:00 even when latency is fine, why?
Peak-hour traffic surge can push p95 from 800ms to 1500ms naturally without any underlying issue (more concurrent requests = longer queue depth). Two fixes: (a) raise the peak threshold from 3s to 4s during high-traffic events; (b) use NR’s adaptive baseline alert type, which compares against the same time-of-day on prior weeks rather than a fixed threshold. Adaptive baselining handles seasonal traffic gracefully.
The latency axis is flat at 0ms, what’s wrong?
Almost always a manifest configuration mismatch. The card filters appName = 'checkout-api' but the merchant’s NR account has the app named Checkout Service or bff-checkout. Reconnect the integration and re-select the checkout app from the dropdown during onboarding.