Skip to main content
Card class: Cross-Channel • Category: Ecommerce Platform
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 countsFor 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 treatmentTax-inclusive. Baseline uses total_inc_tax.
ShippingIncluded.
DiscountsAlready deducted (post-discount baseline).
RefundsNot modelled (the card is a real-time outage estimate, not an accounting figure).
Incomplete / Declined ordersIncluded in baseline. The estimate is “what would normally be transacting right now” using gross BC revenue.
Cancelled ordersIncluded in baseline.
CurrencyMulti-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 / sourcesAll 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 settingDefaults: 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 windowRT (real-time, recomputed each minute while incidents are open)
Alert trigger>$0 (any incident open with revenue impact)
Rolesowner, 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.
MetricValue
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 coefficient1.0 (P1 dominates; P3 subsumed)
Baseline revenue per minute$70
Elapsed minutes since incident open18
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)istheoperations−teamSLAargument.∗∗"Weneedtofixthiswithin4hoursorwelose16.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

CardWhy pair it with Revenue at Risk from Incident
BC Alert Revenue DropThe alert that often co-fires with this card. Real-time drop confirms the incident is impacting revenue.
BC Alert Channel Revenue DropPer-channel version, useful when the incident is scoped to a single channel.
Total RevenueThe denominator. Lets finance compute incident cost as a percentage of revenue.
BC XC Revenue at Risk Decline LiveThe decline-rate-spike-driven version of this card; complementary signal.
datadog.dd_open_incidentsThe Datadog-side incident list this card draws from.
newrelic.nr_open_incidentsNew Relic equivalent.
BC Failed Orders CountThe lagging confirmation, after the incident resolves, did the failure count actually spike?
BC Decline RateIf 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 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:
ReasonDirection
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:
CardExpected relationshipNotes
datadog.dd_open_incidentsThe list of open incidents this card usesOne-to-one mapping
newrelic.nr_open_incidentsSame for New RelicOne-to-one mapping
Total RevenueThe baseline sourceDirect dependency
BC Alert Revenue DropThe lagging real-time confirmationShould fire shortly after this card crosses meaningful thresholds

​
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 or book a demo to see this metric running on your own data.