> ## 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 at Risk (active incidents), BigCommerce > Live $/min loss while Datadog/NewRelic incidents are open. The CFO single-number during outages. 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:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Live \$/min loss while Datadog/NewRelic incidents are open. The CFO single-number during outages. ## At a glance > Live dollars-per-minute revenue loss while Datadog or New Relic incidents are open against the BC store. Cross-connector view: open incident count × baseline revenue rate × incident-impact-coefficient. The CFO-facing single number during an active outage, the answer to "how much is this costing us right now?". | | | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | For each open incident in Datadog / New Relic: `(baseline_revenue_per_minute × impact_coefficient × elapsed_minutes)`, where baseline\_revenue\_per\_minute is the prior 7-day average for the current wall-clock minute and impact\_coefficient is set per-incident (P1 = 1.0 = full-store-down, P2 = 0.5, P3 = 0.2). Summed across all open incidents. | | **VAT / tax treatment** | **Tax-inclusive.** Baseline uses `total_inc_tax`. | | **Shipping** | Included. | | **Discounts** | Already deducted (post-discount baseline). | | **Refunds** | Not modelled (the card is a real-time outage estimate, not an accounting figure). | | **`Incomplete` / Declined orders** | Included in baseline. The estimate is "what would normally be transacting right now" using gross BC revenue. | | **Cancelled orders** | Included in baseline. | | **Currency** | Multi-currency baseline without FX, the live \$/min figure is a mixed-currency total for international stores. Single-currency stores see correct per-minute figures. | | **Channels / sources** | All channels in baseline. An incident scoped to a single channel can be set to a fractional impact coefficient (e.g. POS-only outage at 0.05 if POS is 5% of revenue). | | **Impact coefficient setting** | Defaults: P1 (full storefront down) = 1.0, P2 (one channel / region down) = 0.5, P3 (degraded performance) = 0.2. Merchants can override per-incident in the Vortex Mind incident-config UI. **The coefficient is the dominant factor; setting it correctly matters more than the baseline math.** | | **Time window** | `RT` (real-time, recomputed each minute while incidents are open) | | **Alert trigger** | `>$0 (any incident open with revenue impact)` | | **Roles** | owner, finance, operations | ## Calculation Calculated automatically from your BigCommerce 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 US homewares brand on BigCommerce Enterprise. 14:30 UTC on 12 Apr 26, 18 minutes into an incident. Baseline revenue rate at this hour: \$70/minute. | Metric | Value | | ------------------------------------------- | -------------------------------------------------------- | | Open incident: P1 storefront down (Datadog) | impact 1.0 | | Open incident: P3 search slow (New Relic) | impact 0.2 (additive subset, mostly overlapping with P1) | | Effective coefficient | 1.0 (P1 dominates; P3 subsumed) | | Baseline revenue per minute | \$70 | | Elapsed minutes since incident open | 18 | | **Live revenue at risk (this card)** | **\$1,260** | | Per-minute burn rate | \$70/min | | Projected at 30 min (if not resolved) | \$2,100 | | Projected at 60 min (if not resolved) | \$4,200 | | Projected at 4h (full work day) | \$16,800 | What's interesting: 1. **The number rises in real-time.** Every minute the incident stays open, the figure grows. Refresh the dashboard during the war-room call; the live counter is uncomfortable to watch, which is the point. 2. \*\*The 4-hour projection ($16.8k) is the operations-team SLA argument.** "We need to fix this within 4 hours or we lose $16.8k" is a different conversation than "the storefront is down". Ops gets prioritisation, finance gets visibility, leadership gets context. 3. **Coefficient setting is the load-bearing decision.** A storefront-fully-down at 1.0 is unambiguous. A "one payment method down" at 0.4 (because that method is 40% of orders) is judgement-based. **Set coefficients in advance** during incident-runbook prep, not during the heat of the incident. 4. **The card stops counting once the incident is resolved.** Total recorded loss at resolution is the post-mortem figure, the basis for "this incident cost us \$X" reporting. How to use this card: 1. **Display on a war-room dashboard during P1/P2 incidents.** The live \$/min figure is psychologically important; people work faster when they can see the cost. 2. **Roll up into post-mortem reports**, total elapsed × coefficient × baseline rate = incident cost. 3. **Compare across incidents** to inform infrastructure investment, the highest-cost incident type is the one to spend on prevention for. 4. **Use the coefficient column** to remind teams that not all incidents are full-store outages, set the right coefficient and the math follows. ## Sibling cards merchants should reference together | Card | Why pair it with Revenue at Risk from Incident | | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | [BC Alert Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/revenue-drop-alert) | The alert that often co-fires with this card. Real-time drop confirms the incident is impacting revenue. | | [BC Alert Channel Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/channel-revenue-drop-alert) | Per-channel version, useful when the incident is scoped to a single channel. | | [Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | The denominator. Lets finance compute incident cost as a percentage of revenue. | | [BC XC Revenue at Risk Decline Live](/nerve-centre/kpi-cards/bigcommerce/revenue-at-risk) | The decline-rate-spike-driven version of this card; complementary signal. | | [`datadog.dd_open_incidents`](/nerve-centre/datadog/dd_open_incidents) | The Datadog-side incident list this card draws from. | | [`newrelic.nr_open_incidents`](/nerve-centre/newrelic/nr_open_incidents) | New Relic equivalent. | | [BC Failed Orders Count](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-count) | The lagging confirmation, after the incident resolves, did the failure count actually spike? | | [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) | If the incident was payment-side, decline rate confirms impact. | ## Reconciling against the vendor's own dashboard **Where to look in BigCommerce Control Panel:** BigCommerce **does not surface incident-driven revenue at risk natively.** The data is cross-connector: incidents from Datadog / New Relic, baseline revenue from BC. To approximate manually: 1. [BC Status](https://status.bigcommerce.com) confirms BC-platform incidents. 2. Datadog or New Relic incident dashboards show your application-side incidents. 3. Multiply elapsed minutes × your baseline minute revenue × impact coefficient. **Why our number is a model estimate, not a ground-truth measurement:** | Reason | Direction | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | **Impact coefficient is judgemental**. A "P1 storefront down" might still be processing some orders if a CDN cache is serving cached pages. Setting coefficient = 1.0 over-estimates. | Could be HIGHER than reality | | **Baseline rate uses prior-7-day average**. If today is a sale day with elevated baseline, the model under-estimates. | Could be LOWER than reality on peak days | | **Customer behaviour during outages**. Some customers retry after the outage clears (recovery); others abandon permanently. The card models the *gross* loss at incident time, not the net. | Over-states net loss; under-states gross | | **Time zone**. Baseline uses UTC matched-minute. | Marginal | | **Multi-incident overlap**. If two incidents are open, we sum coefficients capped at 1.0; some real-world incident pairs over-attribute. | Mostly correct | **Cross-connector reconciliation:** | Card | Expected relationship | Notes | | ------------------------------------------------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------- | | [`datadog.dd_open_incidents`](/nerve-centre/datadog/dd_open_incidents) | The list of open incidents this card uses | One-to-one mapping | | [`newrelic.nr_open_incidents`](/nerve-centre/newrelic/nr_open_incidents) | Same for New Relic | One-to-one mapping | | [Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | The baseline source | Direct dependency | | [BC Alert Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/revenue-drop-alert) | The lagging real-time confirmation | Should fire shortly after this card crosses meaningful thresholds | ***
Same-metric documentation cross-reference (for agencies running multiple platforms) * [`shopify.xc_revenue_at_risk_from_incident`](/nerve-centre/shopify/xc_revenue_at_risk_from_incident) (planned) * [`adobe_commerce.xc_revenue_at_risk_from_incident`](/nerve-centre/adobe_commerce/xc_revenue_at_risk_from_incident) (planned)
## Known limitations / merchant FAQs **The number scares me, is it really that much?** Order-of-magnitude correct, not penny-precise. The card is a real-time estimate using prior-week baseline rates. The directional signal ("we're losing material money right now") is reliable; the exact dollar figure is ±20-30% accurate. **Use it for prioritisation and post-mortem reporting, not for accounting reconciliation.** **My incident is open but the storefront still works, why is the card showing \$/min loss?** Check the impact coefficient. If it's set to 1.0 and the storefront is still processing orders, the coefficient is wrong. Set it to a lower value (0.2-0.5 depending on actual user impact) and the figure shrinks accordingly. **The coefficient is the dial that matches the model to reality.** **How do I set the coefficient when the impact is unclear?** Default conservative (1.0 = full down) if you genuinely don't know; this protects against under-counting. As the war room gathers data ("only payments are affected", "it's only on EU traffic"), reduce the coefficient to match. Document the coefficient changes in the incident timeline for the post-mortem. **My incident is over but the card still shows a number, why?** Either the incident wasn't closed in Datadog / New Relic (close it explicitly), or the card is showing the historical incident-cost summary. The live \$/min counter stops once all open incidents are closed; the cumulative dollar figure persists in the historical record. **Should I show this on a public-facing dashboard?** Internal only. Customer-facing exposure of "we're losing \$X/min right now" creates poor optics and can be misinterpreted by media or competitors. The card belongs in the war-room dashboard and exec-team Slack, not on a status page or public site. **Why use 7-day baseline instead of yesterday's same-hour?** 7 days handles weekly seasonality; yesterday's same-hour can be unrepresentative (a sale day, a quiet day, a different-shape traffic pattern). 7-day rolling is more robust for incident-baseline math. **Multi-currency: the dollar figure looks wrong, what currency is it in?** For multi-currency stores the figure is mixed-currency. **Read the trend, not the absolute level.** A figure that's growing \$/min during an open incident still tells you the right story even if the units are mixed. Single-currency stores see correct dollar figures. **My biggest customer placed a \$50k order during the incident, did that get counted?** The card uses an averaged baseline; it doesn't see individual orders in real-time. A single large order during the incident period would shrink the apparent loss but the card wouldn't reflect it until the next baseline-recompute cycle. **Don't game the figure**; the value is in averaged behaviour, not single-order outliers. **Should I include this in vendor SLA-credit calculations?** Possibly. Some BC contracts have SLA credits for storefront-down minutes. The post-mortem incident-cost figure (cumulative final value of this card) is a useful starting point for SLA-credit conversations, but vendors will require their own ground-truth measurement. **Treat this card's number as your internal estimate; expect the vendor to dispute it.** **Does the card model recovery (customers retrying after the incident clears)?** No. It models the gross loss during the incident. Some fraction of those customers will return after resolution; healthy stores recover 30-50% of incident-time revenue within 24-72 hours. **Compute net loss = gross loss × (1 - recovery\_rate)** for finance reporting; the gross figure is for operations response. *** ### Tracked live in Vortex IQ Nerve Centre *Revenue at Risk (active incidents)* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce 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.