> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Revenue Lost / Min (active incidents), New Relic > Live $/min loss while incidents are open. Stops being academic and starts being the COO's number. How to read it, why it matters, and how to act on it. **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Monitoring](/nerve-centre/connectors#connectors-by-type) > 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 on `checkout-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) | **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 | Card | Why pair it with Revenue Lost / Min | | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/newrelic/revenue-at-risk) | Forward-looking risk number. Pair to compare predicted (risk) vs realised (loss); agreement validates the model. | | [Active Incidents](/nerve-centre/kpi-cards/newrelic/active-incidents) | The trigger condition. The card only evaluates while at least one CRITICAL/HIGH is open. | | [Operational Health Score](/nerve-centre/kpi-cards/newrelic/operational-health-score) | Composite parent. Score drops typically map to non-zero loss within 1, 3 minutes. | | [Conversion Drop During Incidents](/nerve-centre/kpi-cards/newrelic/conversion-drop-during-incidents) | Sister cross-platform card. Loss in dollars = conversion drop x baseline traffic x AOV; same incident, different lens. | | [Cart Abandonment During 5xx Spikes](/nerve-centre/kpi-cards/newrelic/cart-abandonment-during-5xx-spikes) | Funnel-step view of the same incident. Tells you *where* in checkout customers dropped off. | | [Datadog Revenue Lost / Min](/nerve-centre/kpi-cards/datadog/revenue-lost-min) | Cross-connector peer. Same composite shape using DD incident state. | | [Shopify Sales / Min](/nerve-centre/shopify/sales_per_minute) | The actual-sales input. Open this card directly if you want raw sales view without the loss derivation. | | [GA4 Conversion Rate](/nerve-centre/kpi-cards/google-analytics/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-platform composite, no native NR equivalent. The closest equivalent screens for the input signals: * [Alerts & AI > Issues & Activity](https://one.newrelic.com/alerts-ai) for the incident-state input. * [Dashboards](https://one.newrelic.com/dashboards) > custom merchant dashboard with a sales-per-minute panel (typically pulled from a Shopify / BigCommerce custom data ingest). For the actual-sales-per-min input, compare against the merchant's commerce platform's live dashboard (Shopify Admin > Analytics > Live View, or equivalent). **Why our number may legitimately differ from a manual estimate:** | 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 | **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`](/nerve-centre/kpi-cards/datadog/revenue-lost-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.
Same-metric peers on other connectors | Connector | Card | Notes | | --------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Datadog | [`dd_xc_revenue_lost_per_min`](/nerve-centre/kpi-cards/datadog/revenue-lost-min) | Same composite shape using DD incident state. Should match within 25% during incidents. |
## 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 down `Transaction` 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. *** ### Tracked live in Vortex IQ Nerve Centre *Revenue Lost / Min (active incidents)* is one of hundreds of KPI pulses Vortex IQ tracks across New Relic and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.