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 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 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 14k/day brand losing 200/hr = 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.
- 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.
| 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. |
| 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
WARNINGnotCRITICAL. The card looks for the merchant’s defined “open incident” definition; tune the severity threshold in Settings → Connectors → Datadog → Severity threshold.
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 50/min. Vortex IQ Mind auto-prioritises incidents by this figure.