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.
| What it counts | loss_per_min = max(0, baseline_sales_per_min - actual_sales_per_min) evaluated minute-by-minute while at least one CRITICAL or HIGH NR incident is open. When all incidents close, the card returns to $0. |
| NerdGraph endpoint | NR side: actor.account.aiIssues.issues(filter: {states: [ACTIVATED]}) to detect open-incident state. Commerce side: live order count / min from the connected commerce sibling (Shopify OrderCreated webhook stream, BigCommerce orders API, or Adobe Commerce checkout-success events). |
| Metric basis | Hard-counted minute aggregation. actual_sales_per_min from real Order events; baseline_sales_per_min from rolling 28-day same-day-of-week, same-time-of-day average. |
| Aggregation window | 1-minute rolling for both actual and baseline. Card updates every 30s on standard sync; live on Webhook-driven Pro plans. |
| Browser vs APM scope | NR side reads incident state across all NR product lines (APM, Browser, Infrastructure, Synthetic, Logs). Commerce side reads completed orders only, no carts, no abandons. The cross-join is “during the period the incident was open, what was the gap between expected and actual sales?” |
| Severity threshold | Card only evaluates when at least one CRITICAL or HIGH incident is open. P3/MEDIUM incidents do not trigger evaluation; the assumption is they’re not customer-facing enough to map to revenue. |
| Filtered hosts / services | NR scope: all entities by default; can be narrowed to revenue-critical services. Commerce scope: the merchant’s primary connected store; multi-store merchants get one card per store. |
| Sample basis | Order data is unsampled (commerce platforms emit every order). Incident state is unsampled. The card is exact, not estimated. |
| Time zone | UTC for evaluation; account timezone for chart display. Baseline computation respects the merchant’s local timezone for “same time-of-day” alignment. |
| Time window | RT |
| Alert trigger | >$0. Any non-zero realised loss with an open incident is worth a notification. |
| Roles | owner, finance, operations |
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:
| Minute | Open incident | Baseline sales/min | Actual sales/min | Loss/min |
|---|---|---|---|---|
| 19:32 | iss-7af2c1 | £820 | £790 | £30 |
| 19:33 | iss-7af2c1 | £825 | £610 | £215 |
| 19:34 | iss-7af2c1 | £830 | £210 | £620 |
| 19:35 | iss-7af2c1 + iss-7af2d4 | £830 | £80 | £750 |
| 19:36 | iss-7af2c1 + iss-7af2d4 | £825 | £60 | £765 |
| 19:37 | iss-7af2c1 + iss-7af2d4 | £820 | £55 | £765 |
| 19:38 | iss-7af2c1 + iss-7af2d4 | £820 | £80 | £740 |
| 19:39 | iss-7af2c1 (other resolved) | £820 | £190 | £630 |
| 19:40 | iss-7af2c1 | £825 | £410 | £415 |
| 19:41 | iss-7af2c1 | £830 | £680 | £150 |
| 19:42 | iss-7af2c1 | £830 | £805 | £25 |
| 19:43 | (all resolved) | £830 | £820 | £0 (card stops evaluating) |
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
| Card | Why pair it with Revenue Lost / Min |
|---|---|
| Revenue at Risk (live) | Forward-looking risk number. Pair to compare predicted (risk) vs realised (loss); agreement validates the model. |
| Active Incidents | The trigger condition. The card only evaluates while at least one CRITICAL/HIGH is open. |
| Operational Health Score | Composite parent. Score drops typically map to non-zero loss within 1, 3 minutes. |
| Conversion Drop During Incidents | Sister cross-channel card. Loss in dollars = conversion drop x baseline traffic x AOV; same incident, different lens. |
| Cart Abandonment During 5xx Spikes | Funnel-step view of the same incident. Tells you where in checkout customers dropped off. |
| Datadog Revenue Lost / Min | Cross-connector peer. Same composite shape using DD incident state. |
| Shopify Sales / Min | The actual-sales input. Open this card directly if you want raw sales view without the loss derivation. |
| GA4 Conversion Rate | Customer-side outcome. Conversion drop confirms the loss is real-customer-experienced, not a baseline-anomaly artifact. |
Reconciling against the vendor’s own dashboard
Where to look in New Relic: This card is a Vortex IQ cross-channel 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).
| Reason | Direction of divergence |
|---|---|
| Baseline staleness. Baseline is rolling 28-day same-day-of-week, same-time-of-day. If the baseline period included an unusually low-traffic day (a holiday, a campaign down-day), the baseline reads low and the loss reads low. | Card understates loss |
| Account timezone vs UTC. Baseline uses merchant local timezone for “same time-of-day”; NR side runs UTC for incident state. Boundary-period evaluation can drift the loss number by 5, 15% on the most recent minute. | Either direction |
| Order webhook lag. Shopify and BigCommerce order webhooks arrive 200ms, 4s after order creation; the card’s actual-sales-per-min reading lags real ground truth by that interval. During fast-moving incidents the live card can show a 10, 20% optimistic actual figure (orders are mid-flight, not yet counted). Vortex IQ Mind backfills 30 minutes after incident close. | Card understates loss in real-time |
| Multi-currency. Baseline and actual are summed in the merchant’s primary currency. Multi-region stores with secondary currencies are normalised at the daily FX close; intra-day FX movements can introduce 1, 2% drift. | Either direction |
| Recovery latency. Some lost sales recover when customers retry within 15, 30 minutes. The live card shows gross loss; net loss settles ~30 minutes after incident close at typically 70% of gross. | Card overstates permanent loss |
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.