Live $/min loss while incidents are open. Stops being academic and starts being the COO’s number.
At a glance
Live, hard-counted dollars-per-minute that the merchant has already lost, computed from the gap between actual sales/min and the prior-baseline sales/min during the open-incident window. Different from nr_revenue_at_risk (which is forward-looking risk); this card is realised loss.
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 brand with NR APM on the storefront. At 19:32 on 02 May 26 a CRITICAL incident fires oncheckout-api (DB connection pool exhaustion). The card stream over the next 12 minutes:
Cumulative loss over the incident window: roughly £5,150 across 11 minutes, or an average of £468/min. The card peaks at £765/min at the worst point (19:36, 19:37, when ~93% of expected sales were missing).
What this card tells you that
nr_revenue_at_risk doesn’t. The risk-side card said £4,470/hour at the start (a forward-looking projection from operational state). The realised-loss side card said £5,150 across 11 minutes (~£28k/hour rate during the worst window). The two numbers should agree within ~25% over the full incident; they typically do because the operational-state model is calibrated against historical realised-loss data via the back-testing loop.
Why the loss recovers some sales. Customers who hit a 5xx during checkout often retry within 5, 15 minutes. The minute-by-minute loss is gross loss; some of those customers complete in a later minute, which shows up as the “recovery” between 19:39 and 19:42 even though the incident is still open. Net loss ≈ gross loss × 0.7 typically (30% of customers eventually complete). Vortex IQ Mind reconciles this 30 minutes after the incident closes and emits a final “settled loss” number on the change-history feed.
Apdex calibration interaction. During the 19:35, 19:38 worst window, Apdex on checkout-api was 0.31 (below 0.5 = most users frustrated). This isn’t surprising, the frustrated bucket is the lost-sales bucket. The relationship between Apdex and lost-sales is roughly linear in the frustrated zone: Apdex of 0.5 corresponds to ~50% sales loss; Apdex of 0.3 to ~70% sales loss; Apdex of 0.1 to ~90% sales loss.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic: This card is a Vortex IQ cross-platform composite, no native NR equivalent. The closest equivalent screens for the input signals:- Alerts & AI > Issues & Activity for the incident-state input.
- Dashboards > custom merchant dashboard with a sales-per-minute panel (typically pulled from a Shopify / BigCommerce custom data ingest).
Cross-connector reconciliation:
This card joins NR incident state with commerce-sibling order data. The same composite shape exists on Datadog (
dd_xc_revenue_lost_per_min) using DD’s incident state instead. Both should read the same actual-sales-per-min input (same commerce sibling), so disagreements come purely from incident-state differences. A 25%+ persistent gap during an incident indicates one platform’s incident state didn’t capture the relevant condition.
The card is reconciled forward (against settled loss) every 30 minutes after an incident closes: Vortex IQ Mind compares the live-time gross-loss number to the settled-loss number after recovery. The settled-loss number is the merchant’s authoritative “this is how much we actually lost” figure for post-incident review; the live number is the duty-engineer signal during the incident.
Known limitations / merchant FAQs
NR vs Datadog: which platform’s incident state should I use for revenue-loss attribution? The one with broader coverage of your stack. If NR Alerts covers your storefront and checkout services and Datadog Monitors covers your infrastructure, use NR for application-level loss attribution and DD for infrastructure-level. If the same incident shows up on both with peer alerts, either platform produces the same loss figure (same actual-sales input). Apdex math: does Apdex predict loss? Approximately. In the frustrated zone (Apdex < 0.5), the relationship between Apdex and loss is roughly linear: Apdex 0.3 ~ 70% sales loss, 0.1 ~ 90% loss. Outside the frustrated zone the relationship is much weaker; Apdex 0.8 vs 0.9 produces ~5% sales difference, well within baseline noise. Read this card alongside Apdex during incidents; Apdex tells you the satisfaction state, this card tells you the dollar consequence. NRQL retention: this card uses live data, but can I see historical loss? Yes. The card emits a settled-loss event 30 minutes after each incident closes; those events are retained in Vortex IQ’s incident-history store for 12 months. To see historical loss, open Vortex Mind > Incident History. NRQL retention applies to the live evaluation window (5-min and 1h windows are well inside the 8-day NR retention). NR and Datadog disagree on loss by 30%, who’s right? Almost always an incident-state coverage gap: one platform’s monitor didn’t fire on the same condition the other did. The actual-sales input is the same (same commerce sibling), so any disagreement traces to incident-state differences. Audit alert parity if cross-platform consistency matters. Sampling: can sampling make this card wrong? No. Order data (the actual-sales input) is unsampled, every order produces an event from the commerce platform. Incident state is unsampled. The card is exact, not estimated. NR’s transaction-event sampling does not affect this card. Multi-account: my US and EU stores have separate revenue patterns, can the card handle both? Yes. The card pairs each NR account with its corresponding commerce sibling. US loss and EU loss are computed independently. The Nerve Centre stack panel can sum them for a global figure or display them side-by-side; most CFOs prefer the regional split. Ingest cost vs visibility tradeoff: can I reduce NR ingest without breaking this card? Yes. The card uses NR for incident state only (not for raw event evaluation). Sample downTransaction events freely, alerting accuracy is preserved as long as your conditions evaluate on rates not raw counts. Order data is from the commerce platform, unaffected by NR ingest. So this card stays accurate across the full range of NR ingest configurations.
Alert tuning playbook: my alert fires for tiny losses (£10/min) below noise, how do I quiet it?
Two levers: (a) raise the floor to ”>£100/min” if you want to ignore residual customer-experience drag during minor incidents; (b) require sustained loss (“must be >£0 for 5 minutes”) to suppress single-minute baseline fluctuation. Most merchants use option (a) because £10/min residual loss for 5 minutes during a P3 alert is rarely worth a notification.
The loss spiked then immediately recovered, was that real?
Two possibilities: (a) real but brief, a 60-second outage during which 100% of inflight checkouts failed and customers retried successfully on the next minute; (b) order-webhook lag, the commerce platform’s webhook delivery was delayed by 30, 60s producing a temporary “actual = 0” reading that recovered when the queue caught up. Vortex Mind’s settled-loss event after incident close disambiguates the two.