Skip to main content
Card class: Cross-Channel • Category: Ecommerce Platform
Live $/min loss while a monitoring incident is open, the COO’s hot-button number during outages.

​
At a glance

Live revenue loss estimate while a Datadog or New Relic incident is open against the merchant’s Shopline storefront or checkout. Translates “the site is degraded” into “the brand is losing HK$ 1,200 / minute right now”. The COO’s hot-button number during incidents.
What it counts(active_incident_minutes) x (shopline.revenue_per_min over trailing 90D average) x (estimated_traffic_loss_pct). Returned in merchant reporting currency.
Source dataDatadog Synthetic / Real-User-Monitoring incidents (or New Relic equivalent) joined to Shopline 90D revenue per minute. The “estimated_traffic_loss_pct” is derived from the incident’s tagged severity (P1: 70% loss, P2: 40%, P3: 15%, P4: 5%).
CurrencyMerchant reporting currency, FX-converted at incident-open time.
Refunds / cancellationsNot relevant; this is a forward-looking loss estimate, not an order count.
What “incident” meansAn open monitoring incident (status != resolved) tagged to the Shopline storefront or checkout flow. Tags must include service:shopline-storefront or service:shopline-checkout (or the merchant’s equivalent).
Why “estimated”The actual loss depends on traffic patterns at the moment of incident; we use 90D averages as the baseline. Real loss can be 50% lower (off-peak hours) to 200% higher (peak hours).
Time windowRT. The dollar number ticks up every minute the incident remains open.
Alert trigger>$0 while incident open. The hero-tier “this is happening right now” signal.
SentimentNone directly; the dollar value is the urgency.
Rolesowner, finance, engineering, operations. The card crosses every C-level discipline because incidents do.
Only whenhas_monitoring_sibling = true (Datadog or New Relic connected).

​
Calculation

Calculated automatically from your Shopline data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

​
Worked example

An APAC fashion brand running Hong Kong Shopline + Datadog APM, incident open at 14:30 HKT on a Sunday (the brand’s peak-traffic window). The brand’s checkout service started returning 500 errors at 14:18; Datadog raised a P1 incident at 14:21. By 14:30 the incident has been open for 9 minutes.
InputValue
Incident severityP1
Incident open since14:21 (9 min)
Shopline 90D avg revenue / min (Sunday peak)HK$ 480 / min
Estimated traffic-loss multiplier (P1)70%
Revenue at risk so farHK480x9x0.70=HK 480 x 9 x 0.70 = HK 3,024
Continuing run-rateHK$ 336 / min
Loss so far:        HK$ 3,024
If unresolved 30 min: HK$ 10,080
If unresolved 60 min: HK$ 20,160
If unresolved 90 min: HK$ 30,240
What it means. At 14:30 the brand has lost ~HK3,024ofexpectedrevenue.Everyadditionalminutecosts HK 3,024 of expected revenue. Every additional minute costs ~HK 336. The incident is happening on a Sunday peak-traffic window, which is the worst possible time; the same incident on a Tuesday morning would cost ~HK$ 80 / min, less than a quarter. The action. The card’s value is in escalation. At HK3,024theincidentis"annoying";atHK 3,024 the incident is "annoying"; at HK 30,240 (90 minutes in) the incident becomes a board-level event. The card translates engineer-time into dollar-time, which lets the COO make the call on whether to escalate to vendor support, declare incident commander, or page in extra responders. Most APAC merchants have an internal SLA that “any incident over HK$ 10,000 of revenue at risk auto-escalates”; this card is what triggers the rule. By 15:18 (60 minutes in) the engineering team identifies a Stripe gateway TLS handshake issue, applies the fix, Datadog auto-resolves the incident at 15:24. Final loss for the incident: HK480x63x0.70=HK 480 x 63 x 0.70 = HK 21,168. The post-incident review uses this card’s history to quantify the cost of slow detection vs slow resolution; the brand’s mean-time-to-detect (3 minutes via Datadog Synthetic) was good, but the mean-time-to-resolve (63 minutes) was the dominant cost driver.

​
Sibling cards merchants should reference together

CardWhy it matters next to revenue-at-riskWhat the combination tells you
Total RevenueThe denominator.Lets you size the incident loss against typical revenue (a HK$ 30k loss is a quarter of a normal day, useful framing).
Revenue Drop AlertIndependent confirmation.If this card is firing, the revenue drop alert should also be firing within minutes; if not, the incident may be partial.
Datadog Active IncidentsThe upstream signal.The incident count from Datadog drives this card’s open / closed state.
New Relic Active IncidentsAlternate monitoring source.Same role as Datadog; the card uses whichever is connected.
Avg Time-to-Paid (hrs)Payment-rails health.Some incidents are payment-rail issues, not site issues; check both during diagnosis.
Payment MethodsMethod-specific outage.A sudden FPS share drop during the incident pinpoints FPS as the failing rail.
Shopline Health ScoreComposite.Health score drops sharply during incidents; this card is the financial translation.

​
Reconciling against the vendor’s own dashboard

Where to look: There is no single vendor view of this; the data is split across two systems. The closest manual workflow:
Datadog -> Service Map -> Incidents (incident timeline + severity) Shopline Admin -> Reports -> Sales report (revenue / minute over the incident window)
The merchant has to FX-convert and multiply manually unless they run a runbook tool that does the join. Why our number may legitimately differ from a manual estimate:
ReasonDirectionWhy
Traffic-loss multiplierEitherWe use severity-tagged defaults (P1 70%, P2 40%, etc); a manual estimate may use the actual real-time traffic drop measured in Datadog RUM, which is more precise. The card’s drill-down lets the merchant override.
Baseline periodEitherWe use 90D average revenue / min; some merchants prefer “same hour same day of week last 4 weeks” for tighter baselines. The drill-down supports both.
FX conversionMarginalWe FX-convert at incident-open time; long incidents can drift if FX moves materially.
Off-incident-tag trafficEitherBuyers sometimes complete orders even during a partial outage (the home-page works, checkout does not). Our card uses estimated loss, which can over- or under-count depending on partial-degradation extent.
Multi-regionIdenticalThe card is per-store; cross-region rollup is a separate view.
Internal identity: shopline_xc_revenue_at_risk_from_incident = (incident_open_minutes) x (revenue_per_min_baseline) x (severity_traffic_loss_pct) The drill-down view shows each input separately, allowing the merchant to override either the baseline or the loss percentage with a real-time-measured number.

​
Known limitations / merchant FAQs

Why is the alert at >$0? Because any open incident represents real loss; the alert is meant to be loud during incidents specifically. Under non-incident conditions the card is dormant and shows zero. Why are the traffic-loss percentages set the way they are? Empirical defaults from APAC merchant incident post-mortems. P1 (full outage on a critical service): typically 70% loss because some buyers retry and convert later. P2 (degraded but functional): 40%. P3 (partial functional issue): 15%. P4 (minor): 5%. The drill-down lets the merchant override per-incident. Can the card go negative? No, by design. If revenue rises during an incident (rare; usually because the incident affected a non-checkout service), the card floors at zero rather than show a confusing negative number. The actual revenue is in shopline_total_revenue. Does this account for refunds during incidents? Indirectly. If buyers refund post-incident due to bad experiences (delayed checkout, double-charge), those refunds show up in shopline_refund_rate over the next 7 days. This card only measures the live loss, not the long-tail. My monitoring tool is neither Datadog nor New Relic. What works? The card supports any monitoring connector that exposes incident state and severity (active_incident_minutes, severity tag). Shopline has integrations with Datadog, New Relic, Better Uptime, and Pingdom; the card runs on whichever is connected. Why does the card sometimes show zero even though my site looks slow? Because no monitoring incident is open, only your subjective perception that the site is slow. The card responds to formal incidents (Datadog raised, severity tagged); slowness without a raised incident does not trigger it. Tighten your Datadog Synthetic monitor thresholds if real slowness is consistently going undetected. How accurate is the dollar number? Within roughly +/-30% for typical incidents. The dominant uncertainty is the traffic-loss multiplier; the revenue-baseline is well-measured. For mission-critical use cases, override the multiplier with the actual real-time traffic drop from Datadog RUM during the incident. Does this update during the incident or only at end? Live during the incident, every 60 seconds. Watching the number tick up in real-time is uncomfortable but useful; it concentrates incident-response attention. Will this card export to a status page or board pack? The card publishes a snapshot timestamp on every refresh; the snapshot can be exported as PNG or pulled via API for status-page or board-deck use. APAC merchants typically attach the snapshot to incident retros.

​
Tracked live in Vortex IQ Nerve Centre

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