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.
| What it counts | Two synchronized timeseries on the same chart: (left axis) percentile(duration, 95) FROM Transaction WHERE appName = 'checkout-api' in milliseconds; (right axis) count(orders) per minute from the connected commerce sibling. Both series are minute-resolution. |
| NerdGraph endpoint | NRQL via NerdGraph: SELECT percentile(duration, 95) FROM Transaction WHERE appName = 'checkout-api' SINCE 24 HOURS AGO TIMESERIES 1 minute. Plus the commerce-sibling order endpoint for the second series. |
| Metric basis | Both series are unsampled at the rate level (NR percentile is sample-stable; orders are unsampled). The visual correlation is what makes this card valuable, not the absolute numbers. |
| Aggregation window | 1-minute resolution over a rolling 24-hour window. Updates every 30s. |
| Browser vs APM scope | APM-only on the latency axis (server-side checkout latency). For full customer-side latency including network and browser, use the RUM equivalent (RUM Page Load p95) which usually adds 800, 1500ms to the APM number. The order axis is unaffected. |
| Severity threshold | The 3-second threshold during peak hours is the SOASTA-derived “perception of brokenness” boundary on commerce checkouts. Anything above 3s on a checkout flow during business hours produces measurable conversion drop. |
| Filtered hosts / services | APM scope: the checkout-api app (or whatever the merchant has tagged as the checkout app during onboarding). Order scope: the merchant’s primary commerce sibling. |
| Sample basis | t-digest percentile is sample-stable (~5ms accuracy at 50% sampling). Order data is unsampled. |
| Time zone | Account timezone for chart axes; UTC for raw timestamps. “Peak hours” definition follows the merchant’s local timezone (typically 09:00, 22:00 weekdays; 10:00, 18:00 weekends). |
| Time window | 24H (rolling 24-hour view) |
| Alert trigger | p95 >3s during peak hours (peak-aware threshold). Off-peak the threshold relaxes to 5s to avoid waking duty engineers for batch-job latency during low-traffic windows. |
| Roles | owner, engineering, finance |
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:
| Window | Checkout p95 | Orders/min | Note |
|---|---|---|---|
| 16:00, 16:55 | 850ms steady | 8.6 / min | Healthy peak |
| 16:55, 17:10 | 850 -> 1,200 -> 1,650ms | 8.6 -> 7.4 -> 5.8 / min | Latency creeping; orders softening |
| 17:10, 17:25 | 2,100 -> 3,400ms | 5.8 -> 3.1 -> 2.0 / min | Above 3s threshold; orders fall sharply |
| 17:25, 17:55 | 3,400ms steady | 1.8, 2.4 / min | Sustained; ~75% drop in orders |
| 17:55, 18:10 | Drops back to 1,000ms after rollback | 2.4 -> 6.8 -> 8.2 / min | Recovery |
| 18:10, 20:00 | 870ms steady | 8.4, 9.1 / min | Back to normal peak |
(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
| Card | Why pair it with Checkout App Health x Sales |
|---|---|
| p95 Response Time | The latency input. Open for the full app-wide percentile (this card is checkout-only). |
| Errors by Transaction | When latency creeps without obvious cause, this drills into which endpoint slow-tail is concentrated on. |
| Database Query Latency p95 | Most common cause of checkout slowdown. Pair when this card moves to confirm DB-level cause. |
| Apdex Score | Satisfaction-weighted view. Pair to see whether the latency move is also moving customer satisfaction. |
| Cart Abandonment During 5xx Spikes | Sister cross-channel card focused on errors instead of latency. |
| Datadog Checkout Health x Sales | Cross-connector peer. |
| Shopify Sales / Min | The order-axis input. Open for raw view without the latency overlay. |
| GA4 Checkout Funnel | Whole-funnel customer-side view. Pairs to confirm latency-driven drop is felt in the early funnel steps too. |
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).
| Reason | Direction of divergence |
|---|---|
| Account timezone vs UTC. NR APM chart axes follow account timezone; NRQL via Vortex IQ runs UTC. Boundary-period rollups can show 5, 10ms drift on the latency axis. | Either direction at boundaries |
| NRQL retention windows. Full-resolution data is 8 days standard; older 24-hour windows on day 7 or 8 may show very slightly coarser percentile estimates. The card’s 24-hour window stays inside the retention window unless backfilled. | None for live |
| Order webhook lag. Order count per minute lags real-time by 200ms, 4s depending on the commerce platform’s webhook delivery. The latest minute on the order axis can read ~10% low until the queue catches up. | Card understates orders on most-recent minute |
| NerdGraph rate limits. Default 3,000 points / minute / account. The 1-minute resolution NRQL is heavier than typical KPI queries; rate-limiting can stale the latency axis by 30, 60s during heavy investigation. | Stale, not wrong |
Filter scope. Vortex IQ scopes appName = 'checkout-api'. If the merchant renames the app or deploys a new checkout service without updating the manifest, the latency axis goes flat (no data) until reconfigured. | Card may show 0 latency |
Known limitations / merchant FAQs
NR vs Datadog: which is better for this kind of cross-channel 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-channel 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.