Skip to main content
Metrics type: Cross-Platform Metrics • 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?”.

​
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. 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

​
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: Cross-connector reconciliation:

​
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.