Skip to main content
Metrics type: Cross-Platform MetricsCategory: Monitoring
Live $/min loss while incidents are open. Stops being academic and starts being the COO’s number.

At a glance

The live, per-minute estimate of revenue being lost while a Datadog incident is open. Where Revenue at Risk shows the hourly rate, this card shows the per-minute ticker, which is what the COO and finance team want to read during a live incident. Every minute the displayed value persists is a minute of cost compounding.

Calculation

Calculated automatically from your Datadog 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 UK fashion brand on Shopify with Datadog APM. Baseline revenue at 14:00 GMT (peak): £160/min. A SEV-1 checkout outage opened at 14:23 GMT.
The card displays £56/min with the value highlighted red while the incident is open. Three things this enables:
  1. Live cost framing for the response team. “We have a SEV-1” is engineering jargon; “We are losing £56 per minute right now” is finance language. Both teams now share a number. The COO can walk into the engineering Slack channel and ask “are we still losing £56/min?” instead of asking technical questions; the on-call has a clear KPI for “incident is over”.
  2. The cumulative cost is computed automatically. After 25 minutes the cumulative number reads £1,400. After 90 minutes it reads £5,040. After 4 hours it would be £13,440. The cumulative grows linearly until the incident closes; the per-minute rate is constant unless severity changes (e.g. SEV-1 downgraded to SEV-2 mid-investigation).
  3. The per-minute frame discourages “let’s wait and see if it self-resolves” thinking. Without this card, the team may be tempted to spend 20 minutes investigating before deciding whether to rollback. With “£56/min leaking” displayed live, the team is more likely to rollback immediately and investigate later. The mental model shifts from “diagnose first” to “stop the bleeding first”.
Three takeaways merchants should remember:
  1. Per-minute and per-hour are the same number expressed differently. Use per-minute for live dashboards during an incident; use per-hour for executive briefings, status-page banners, and post-incident summaries. The per-minute figure is the live heartbeat; the per-hour figure is the executive frame.
  2. The card encourages “stop the bleeding first” decisions. Engineering teams trained on “diagnose first, then fix” can be slow to rollback; the live cost ticker counters this with a clear, ongoing financial argument for immediate action.
  3. The cumulative tally during a long incident is sobering. A 4-hour SEV-1 at £56/min is £13,440. Many merchants find that one bad incident per quarter costs more than the entire engineering tooling budget for the year. This is the card that justifies investments in deploy safety, automated rollback, and synthetic monitoring.

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Where to look in Datadog: Datadog does NOT compute or display Revenue Lost / Min; this card is a Vortex IQ-only synthesis. The component inputs come from:
Incidents for the active-incident severity (the formula’s state input). Service Catalog for the service the incident affects.
The commerce-sibling baseline is fetched from the connected Shopify, BigCommerce, or Adobe Commerce platform via that platform’s Order API. Why our number may legitimately differ from a hand-computed estimate: Cross-connector reconciliation:

Known limitations / merchant FAQs

What is the difference between this card and Revenue at Risk? Same number, different units. Revenue at Risk is per-hour (£1,380/hour); this card is per-minute (£23/min). Use this card during live incidents on dashboards and Slack pings; use Revenue at Risk for executive summaries and post-incident reports. The per-minute frame creates urgency; the per-hour frame fits executive comms. Why per-minute, not per-second? Per-second would be jittery (the formula has minute-level resolution because commerce baselines are minute-resolution, not second-resolution). Per-minute is the smallest meaningful unit. Per-second would also feel performative; per-minute is direct without being theatrical. My commerce platform is not connected. What does the card show? “Connect a commerce platform to enable Revenue Lost / Min”. The card requires a commerce sibling for the baseline. Without it, no revenue/min baseline exists to multiply by. Connect Shopify, BigCommerce, or Adobe Commerce. The cumulative tally is shocking. Is the formula too aggressive? Possibly, depending on your traffic mix. The default 35% traffic-loss assumption for SEV-1 is calibrated against typical merchants; if your specific store has a more loyal customer base (high return-rate, branded-search-heavy traffic), shoppers may tolerate slowness better and actual loss is lower. After a few real incidents, compare estimated (this card) vs measured (Conversion Drop During Incidents) and tune the percentage in Settings → Datadog → Revenue-at-Risk Calibration. Does this card include refunds or chargebacks from the incident period? No. The card shows revenue-not-captured during the incident, not revenue-captured-then-refunded. If the incident causes payment-confirmation failures that lead to disputes weeks later, those costs are tracked separately on Stripe Dispute Rate and similar payment-side cards. What happens to the cumulative tally after the incident closes? The cumulative is preserved as a “post-incident summary” entry on the same card for 7 days, then archived. The post-incident view shows: (1) Total cumulative loss, (2) Incident duration, (3) Post-incident measured loss for comparison, (4) The deploy or change that caused the incident if identified. This lets the merchant build institutional memory of incident costs. My Logs API returns 400 No valid indexes. Does this card still work? Yes. Revenue Lost / Min consumes incident state and commerce-sibling baseline; both are independent of Logs. The card says £56/min but my Stripe dashboard shows revenue is barely below baseline. What is happening? Two possible reasons: (1) Shoppers are queuing or retrying and will eventually complete checkout (delayed revenue, not lost); (2) The traffic-loss percentage in the formula is too aggressive for your store. After the incident closes, compare cumulative vs measured loss and recalibrate. Some retail categories (high-loyalty, low-impulse) tolerate incidents much better than others (impulse, discount, fast-fashion). Why does the per-minute number change during an incident even though the severity stays the same? Because the baseline revenue/min varies hour-by-hour. An incident that persists from peak (£160/min baseline) into off-peak (£40/min baseline) will see the displayed loss decrease as the incident continues, even though the engineering problem is unchanged. This is correct: actual revenue loss really is lower at low-traffic hours. Can I see this card for closed incidents? The post-incident summary is available for 7 days on the card itself; the full historical view is available on the Vortex IQ Incident History page (Settings → Datadog → Incident History). For the post-mortem write-up, copy the cumulative loss number and the measured-loss number from Conversion Drop During Incidents.

Tracked live in Vortex IQ Nerve Centre

Revenue Lost / Min (active incidents) is one of hundreds of KPI pulses Vortex IQ tracks across Datadog 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.