Revenue at Risk (live incident), Shopline

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

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 data	Datadog 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%).
Currency	Merchant reporting currency, FX-converted at incident-open time.
Refunds / cancellations	Not relevant; this is a forward-looking loss estimate, not an order count.
What “incident” means	An 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 window	`RT`. 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.
Sentiment	None directly; the dollar value is the urgency.
Roles	owner, finance, engineering, operations. The card crosses every C-level discipline because incidents do.
Only when	`has_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.

Input	Value
Incident severity	P1
Incident open since	14:21 (9 min)
Shopline 90D avg revenue / min (Sunday peak)	HK$ 480 / min
Estimated traffic-loss multiplier (P1)	70%
Revenue at risk so far	HK $480 x 9 x 0.70 = HK$ 3,024
Continuing run-rate	HK$ 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 ~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 HK

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: 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

Card	Why it matters next to revenue-at-risk	What the combination tells you
Total Revenue	The 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 Alert	Independent 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 Incidents	The upstream signal.	The incident count from Datadog drives this card’s open / closed state.
New Relic Active Incidents	Alternate 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 Methods	Method-specific outage.	A sudden FPS share drop during the incident pinpoints FPS as the failing rail.
Shopline Health Score	Composite.	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:

Reason	Direction	Why
Traffic-loss multiplier	Either	We 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 period	Either	We 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 conversion	Marginal	We FX-convert at incident-open time; long incidents can drift if FX moves materially.
Off-incident-tag traffic	Either	Buyers 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-region	Identical	The 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.

Get Started

The AI OS

Revenue at Risk (live incident), Shopline

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