Revenue at Risk (live incident), Shopify

Metrics type: Cross-Platform Metrics • Category: Ecommerce Platform

Live $/min loss while a monitoring incident is open, the COO’s hot-button number during outages.

At a glance

A live $/min revenue-loss estimate computed only while a monitoring incident (Datadog, NewRelic, PagerDuty, Statuspage) is in OPEN state. The COO’s hot-button number during outages, what is this incident actually costing us right now?


What it counts	`(prior_7D_avg_revenue_per_minute - last_5min_revenue_per_minute) × incident_open_duration_minutes`, computed live and updated every 60 seconds. Negative deltas (revenue ABOVE baseline) clamp to zero, the card never shows a “gain” during an incident.
When the card shows zero	When no incident is open across any connected monitoring connector. The card’s purpose is to quantify outage cost, it deliberately stays dark in healthy operation.
VAT / tax treatment	Inherited from `totalPrice`. UK / EU stores see VAT-inclusive £/min loss, US stores see ex-tax loss. The figure displayed matches the merchant’s headline revenue convention.
Shipping	Included (part of `totalPrice`).
Discounts	Already deducted (post-discount baseline).
Refunds	NOT deducted. The baseline is gross revenue; the deficit calculation is gross-to-gross.
Cancelled / voided orders	Included if Shopify indexed them with non-zero `totalPrice`. Voids during the incident window reduce the live revenue and so increase the displayed deficit.
Currency	Multi-currency arithmetic without FX. The deficit is the unconverted £-equivalent shortfall. For multi-currency stores, treat the figure as approximate; the order of magnitude is correct.
Channels / sources	All sales channels affected by the incident. POS often continues working during a storefront outage (in-store sales unaffected), so a high POS share dampens the displayed loss. The card cannot today separate “POS still working” from “online dead”, that’s manual judgement.
Incident sources	Datadog, NewRelic, and Statuspage open-incident webhooks. PagerDuty integration is on the roadmap.
Time window	`RT` (live, recomputed every 60 seconds while an incident is open)
Alert trigger	`>$0 while incident open`, the card is loud whenever an incident is open AND revenue is below baseline
Roles	owner, finance, engineering, operations

Calculation

Calculated automatically from your Shopify 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 Shopify Plus. Average revenue

14,200 / day = roughly

9.86 / minute baseline. At 15:42 EST on 09 Apr 26, Datadog opens an incident on the brand’s checkout API after detecting a 5xx error spike from the Shopify Functions custom-shipping endpoint.

Time (EST)	Event	Revenue / min	Cumulative loss
15:42	Datadog incident opens (severity: HIGH)	$9.50	$0.36
15:50	Engineers confirm Functions endpoint timing out	$4.20	$43.30
16:00	First mitigation attempt, partial recovery	$6.10	$111.10
16:30	Rollback to previous Functions version	$3.80	$362.40
17:00	Recovery, sales returning to baseline	$8.90	$475.20
17:18	Datadog incident closed	$9.70	$479.50

The card’s live read at 17:18 was **

479.50 lost across 96 minutes**, an average loss rate of

5.00 / min during the incident. Six things to notice:

The number is an estimate, not a reconciled figure. It’s computed from the gap between baseline and live revenue. Some of those “lost” sales recovered later (customers retried checkout 30 minutes after); some were truly lost (customers bought from a competitor). The card does not yet model recovery, so the figure is an upper bound.
**The $479 is a small number for THIS brand, but a huge proportion of the incident's value.** A$ 14k/day brand losing $479 in 96 minutes IS material, that's 3.4% of the day's revenue gone in 1.6 hours. Compare to the engineering cost (3 engineers × 1.6 hours ×$ 200/hr = $960), the incident cost roughly$ 1,440 all-in.
The card requires a connected monitoring incident. If Datadog / NewRelic / Statuspage isn’t connected, this card stays dark even during a real outage. That’s deliberate: without a monitoring signal, Vortex IQ can’t distinguish “outage” from “slow Tuesday”.
Multiple incidents = combined window. If Datadog AND NewRelic both have open incidents at the same time, the card shows the loss for the union of incident windows, not the sum. So a 60-min Datadog incident and an overlapping 45-min NewRelic incident produce one figure for the 60-min combined window.
POS dampens the figure. This brand has 2 retail outlets contributing roughly 15% of revenue. POS sales kept happening during the online outage, so the live revenue / min didn’t drop to zero, it dropped to baseline minus online-share. The card naturally accounts for this by reading actual revenue from Shopify, but it can’t tell you “POS healthy, online dead”, that’s a follow-up drill into Revenue by Channel.
The card auto-resolves when the incident closes. Once Datadog flips the incident to RESOLVED, this card stops accruing and freezes at the final figure for 24 hours (visible in the post-incident review), then drops to dark.

Sibling cards merchants should reference together

This card is a composite. It depends on both monitoring and Shopify revenue. Pair these to triage a live incident:

Card	Why pair it with Revenue at Risk
Datadog Incident Count	The trigger source. If this card lights up, Datadog should have a corresponding open incident. If not, the alert came from a different monitoring vendor.
NewRelic Incident Count	Alternate trigger source. Some merchants run NewRelic instead of or alongside Datadog.
Revenue Drop Alert	The Shopify-internal sales-side detector. When BOTH this card and the revenue-drop alert fire together, the cause is unambiguously infrastructure / app, not market.
Total Revenue	The 30D context. Compare the incident-cost figure (this card) against the rolling daily average (Total Revenue) to size the impact.
Conversion Rate	If conversion rate also collapses during the incident window, that confirms checkout is broken (vs traffic dropping).
Unfulfilled Orders	If the incident is on the warehouse / 3PL side, unfulfilled count climbs while revenue may stay healthy. The card focuses on revenue impact; pair with unfulfilled to see operational impact.
Active Ads on Out-of-Stock SKUs	During an extended outage, ads keep spending while the storefront is dead, the OOS card surfaces wasted spend complementing the revenue loss displayed here.
Revenue by Channel	Useful post-incident review. Tells you whether the loss was concentrated in Online Store, POS, or marketplaces.

Reconciling against the vendor’s own dashboard

Where to look in Shopify Admin: Shopify doesn’t have a native “revenue lost during incident” view. The closest manual reconstruction is:

Live View. Shopify’s real-time revenue map, useful for confirming the dip is happening NOW.
Reports → Sales over time, set the range to the day of the incident with hourly granularity. The deficit visible against the prior day’s same hours is roughly equivalent to this card’s figure.
Manual calculation: take the incident duration in minutes, multiply by the prior 7-day average revenue / minute, subtract actual revenue during the window. That’s the figure this card computes automatically.

Other views that look related but aren’t the same:

Statuspage incident timelines: track the OUTAGE duration, not the revenue impact. Pair with this card during post-incident reviews.
Datadog dashboards: track the technical metric (response time, error rate). Useful for diagnosing the cause; this card translates the technical impact into £.
PagerDuty timelines: track the engineering response time. Independent of revenue impact.

Why our number may legitimately differ from a manual reconciliation:

Reason	Direction	Why
Baseline calculation	Either	The card uses prior-7-day average revenue / minute. A different choice (prior-day-same-hour, prior-week-same-day-same-hour) would give a different baseline. The 7D average is robust to single-day anomalies but may understate seasonal effects.
Recovery is not modelled	Ours higher	Customers who retry checkout after the outage and complete are not subtracted from the deficit. The figure is an upper bound. Post-incident reconciliation against the next 24 hours’ revenue can correct for this.
Multi-currency	Approximate	The arithmetic is unconverted; for stores transacting in multiple currencies the deficit is the order-of-magnitude correct.
Multi-incident overlap	Card uses the union	If two monitoring vendors both alert on the same outage, the card uses the combined window (start of first, end of last). Manually adding two separate incident-loss figures double-counts.
POS unaffected	Card understates the online loss	If the outage is online-only and POS continues, the live revenue stays partially healthy and the deficit underestimates the true online-channel loss. Drill into Revenue by Channel for the channel-segmented view.

Cross-connector reconciliation: This card IS a cross-connector reconciliation by design, it cross-references monitoring against Shopify revenue. The relationships:

Card	Expected relationship	What causes legitimate divergence
`datadog.dd_incident_count`	Datadog incident open ↔ this card live	If Datadog has an open incident but this card stays dark, revenue is at or above baseline despite the technical issue. The technical issue may not be customer-facing.
`newrelic.nr_incident_count`	Same	Same caveat.
`shopify.total_revenue`	This card sums to a portion of the Shopify daily revenue deficit	The 30D Total Revenue figure should reflect this card’s daily-cumulative figures over time. Material long-term gaps suggest the baseline calculation needs tuning.
`stripe.stripe_total_revenue`	Stripe should also show the dip during the incident window	If Stripe is healthy but Shopify is dipping, the cause is non-Stripe checkout (PayPal failing, Shop Pay Installments down).

Known limitations / merchant FAQs

Why is this card dark when I know there’s a problem? The card requires an OPEN incident in a connected monitoring connector (Datadog, NewRelic, Statuspage). If the issue is real but no monitoring system has alerted, the card stays dark. Common causes:

The monitoring tool isn’t connected to Vortex IQ. Connect it in Settings → Connectors → Datadog / NewRelic.
The monitoring tool isn’t watching the right thing. A checkout outage that doesn’t trigger a 5xx alert (because the page returns 200 with a JS error) won’t open an incident automatically. Add a synthetic / browser-test monitor to catch UX-level breakage.
The monitoring tool has the alert in WARNING not CRITICAL. The card looks for the merchant’s defined “open incident” definition; tune the severity threshold in Settings → Connectors → Datadog → Severity threshold.

For the Shopify-revenue-only sales-side detector that doesn’t require monitoring, see Revenue Drop Alert. That card fires on revenue-pattern alone. Why does the figure keep climbing even after the issue is fixed? Because the card accrues over the full incident window from OPEN to RESOLVED. If your engineering team fixed the issue at 16:30 but Datadog’s auto-resolve takes 15 minutes to confirm, the figure keeps climbing until 16:45. Manually flip the incident to RESOLVED in Datadog to stop the accrual immediately. Misconfigured auto-resolve (long cool-down windows) is the most common cause of figure inflation. Is this real money lost or theoretical? A mix. The figure is the deficit between baseline revenue and observed revenue during the incident window. Some of that deficit is genuinely lost (customers bought from competitors, abandoned permanently). Some is delayed (customers retried 30 minutes later and completed). The card does not yet model recovery; treat the figure as an UPPER BOUND. For a tighter post-mortem reconciliation, compare the 24h post-incident revenue against the same baseline, the difference between this card’s figure and the post-incident shortfall is the “delayed but recovered” portion. My POS continued to work during the online outage. Does this card still work? It works but understates the impact. The deficit calculation reads total Shopify revenue, which includes POS. If POS contributes 20% of revenue and online dies completely, total revenue drops to about 20% of baseline, the card shows the loss as 80% of baseline × duration, which IS the online-channel loss but underestimates the customer-experience impact. Drill into Revenue by Channel for the per-channel view. Why does the figure differ from what my Shopify Plus account manager calculated? Shopify’s customer-success teams often use a simpler “average revenue / hour × incident duration” calculation. That ignores the rolling baseline and seasonal effects. Vortex IQ uses prior-7-day average per-minute as baseline, which is more robust but produces a different number. Both are estimates; reconcile by sharing methodology in the post-incident review. Multi-currency stores, what currency is the figure in? The figure is the unconverted arithmetic sum across all order currencies, displayed in the card’s display-currency setting (default GBP for UK / EU stores, USD for US stores). For stores transacting in multiple currencies, the figure is order-of-magnitude correct but not FX-precise. Per-currency views are on the roadmap. Can I see historical incident impact (last quarter, last year)? Not from this card today, the card is real-time only. After an incident closes, the figure freezes for 24 hours then drops to dark. The post-incident report (auto-generated by Vortex IQ Mind) preserves the figure historically, accessible via Mind → Incident Timeline. Action playbook when this card is live:

Read the figure aloud in your incident-bridge call. It anchors the urgency for non-technical stakeholders (“we’re losing $5/min” focuses minds faster than “the API is returning 5xx”).
Open the corresponding Datadog or NewRelic incident, the technical detail lives there.
Cross-check Stripe Total Revenue, if Stripe is also dipping, the issue is end-to-end checkout. If Stripe is healthy, the issue is post-Stripe (Shopify-side) or non-Stripe (PayPal etc).
Watch the figure trend during mitigation. A stabilising or shrinking deficit means recovery is happening; a growing deficit means mitigation isn’t working.
After resolution, freeze the post-incident figure (it auto-freezes for 24h) and feed it into the post-mortem. Reconcile against the next-24h recovery to identify “delayed but recovered” volume.
Use the figure to calibrate engineering urgency, an incident costing $5/min is a different priority to one costing$ 50/min. Vortex IQ Mind auto-prioritises incidents by this figure.

Tracked live in Vortex IQ Nerve Centre

Revenue at Risk (live incident) is one of hundreds of KPI pulses Vortex IQ tracks across Shopify 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.

Get Started

The AI OS

Revenue at Risk (live incident), Shopify

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre