Live $/min loss while incidents are open. Adobe merchants disproportionately run observability stacks, this is a high-hit-rate kill-shot.
At a glance
Live dollars-per-minute revenue loss while one or more observability incidents (Datadog, New Relic, PagerDuty, Adobe Commerce Cloud Pro) are open. Multiplies the typical per-minute Adobe grand_total rate (calibrated from the prior 4 weeks of same-DOW same-hour data) by the duration each incident has been open. Adobe Commerce merchants disproportionately run observability stacks; this is a kill-shot card for ops and finance.
Calculation
Worked example
A multi-region apparel brand on Adobe Commerce 2.4.6 with US, UK, and B2B Store Views, running Datadog monitors and PagerDuty incident routing. Tuesday 12 Apr 26, 14:00 GMT. Baseline calibration (median of the four prior Tuesdays at 14:00):
Active incidents at 14:00:
What this is telling the merchant:
- **The headline 115 ticks onto the figure. Engineering, ops, and finance see this in real-time; gives the on-call a hard number to cite when prioritising the page.
- The Stripe webhook failure deduped against the Datadog checkout-latency incident. Both are symptoms of the same root cause (gateway-callback path broken). The card avoids double-counting by deduping on PagerDuty’s
incident_keycorrelation. If the merchant didn’t have PagerDuty correlating, both would count and the figure would be inflated by 22 × 2,536. - The P3 internal-admin incident is weighted to 10% of revenue impact. A slow admin login doesn’t directly stop customers from buying; the card assumes a 10% indirect impact (operations team can’t process queued orders as fast). Configurable per merchant.
- The baseline assumes business-as-usual hourly cadence. A planned promo or BFCM peak would understate at-risk; a planned quiet period (Sunday morning) would overstate. The card uses a 4-week median which smooths out one-off spikes but can’t anticipate today’s specific demand.
- The figure assumes 100% of baseline traffic is lost during the incident. If the incident is partial (say, only US customers affected by a US-only CDN issue), the card overstates by the share of revenue that comes from unaffected Store Views. Configure per-region incident routing in the manifest for accurate localised at-risk figures.
- The figure is gross of refunds and includes
pending_paymentbaseline orders. A high-pending_paymentAdobe store inflates the at-risk by 2-5%. For a “realised cash” at-risk view, recalibrate the baseline tostate IN (processing, complete, closed).
Sibling cards merchants should reference together
This card is the kill-shot. Pair with these to investigate root cause:Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: Adobe Commerce Admin doesn’t have a native “revenue at risk during incident” view, the closest cross-checks are:Reports > Sales > Orders (or Reports > Sales in 2.4.6+) for the same hour vs. baseline. Set the time range to Hourly and look at the latest hour’s revenue against the prior week’s same hour.For Adobe Commerce Cloud (PaaS) merchants:
Adobe Experience Cloud > Commerce > Site-Wide Analysis Tool has incident timelines and surface-level performance metrics. Use it for incident causation analysis; not for revenue impact (it doesn’t quantify dollar loss).Other Adobe Commerce Admin views that look relevant but aren’t:
- System > Notifications: internal Adobe Commerce admin notifications (login, indexer status), not customer-facing incidents.
- System > Tools > Cache Management: cache state, not incident state.
- Reports > Sales > Coupons: irrelevant.
- Stores > Configuration > Advanced > System: configuration only.
Cross-connector reconciliation (when these connectors are connected for this merchant):
This card is a multi-connector synthesis. The honest reads:
Known limitations / merchant FAQs
The card shows $X at-risk but my actual revenue dropped less, why? The card is a baseline-projected loss assuming 100% of expected traffic is impacted. Real incidents are usually partial: some customers retry, some browse to product pages but don’t checkout, some find their flow works while others fail. The actual loss is typically 30-80% of the at-risk figure. Treat the at-risk number as an upper bound, the headline cost-of-incident if nothing converts. The card shows $X at-risk but my actual revenue dropped MORE, why? The baseline didn’t anticipate today’s specific demand. Common causes: (1) a campaign launched today (paid ads, email blast, influencer drop) that the 4-week median can’t see; (2) a holiday or seasonal peak (Black Friday morning); (3) a planned promotion. The card understates at-risk in these conditions. Use the actual revenue gap during the incident as the true loss figure when reporting upward. What’s the difference betweenstate and status and does it affect the at-risk figure?
The baseline uses grand_total summed across all state values. So pending_payment, canceled, holded orders all contribute to the baseline. A high-pending_payment Adobe store inflates the baseline by 2-5%, which inflates the at-risk figure by the same amount. For a “realised cash” at-risk view, recalibrate the baseline to state IN (processing, complete, closed).
My finance team uses base_grand_total, why doesn’t this card?
The baseline could use either. The card defaults to grand_total per Store View, FX-converted to primary currency at indicative daily rates. base_grand_total (FX-converted at order time, frozen) avoids today’s FX noise but undercounts the customer-paid figure. For incident-cost reports to finance, use this card’s figure (grand_total based) and footnote that it’s at customer-paid value, not at remitted-cash value.
My multi-store Adobe Commerce, can the card know which Store View an incident affects?
Only if you configure incident routing in the manifest. By default the card assumes any open incident affects all Store Views (combined baseline). For region-localised incidents (a US-only CDN failure), set up per-Store-View incident routing so the card scales the baseline to only the affected region. Otherwise it overstates by the share of revenue from unaffected Store Views.
Why doesn’t Adobe Commerce dashboard show this?
Adobe Commerce Admin doesn’t natively know about your observability tools. Cloud Pro merchants get some incident telemetry but not revenue impact. This card is the synthesis layer that joins Adobe Commerce revenue data to observability incident data, neither tool does it alone.
My Stripe revenue dropped during the incident but Adobe revenue looks normal, what does that tell me?
Adobe Commerce is creating order skeletons but the Stripe-side capture-confirmation path is failing. Orders sit in pending_payment. The at-risk card may understate the cost because Adobe grand_total looks roughly normal (the orders exist, they just never paid). Cross-check with Order State Distribution to confirm the pending_payment spike, that’s the actual revenue loss.
Why doesn’t Google Analytics agree the incident impacted revenue?
GA4 fires purchase events client-side; if the customer’s checkout failed before the page loaded, GA4 sees a session abandonment but no purchase event, the revenue is missing on both Adobe and GA4. If GA4 sessions are steady but conversions cratered, the issue is at checkout. If both sessions and conversions are steady, the incident is back-office and customer-invisible.
Multi-currency: does FX volatility during a long incident affect the figure?
Yes, but mildly. The card converts each Store View’s per-minute baseline to the merchant’s primary currency at indicative daily FX. A 1-2% FX move over the course of an hour-long incident shifts the at-risk figure by ~1-3%. For incidents lasting days, FX volatility can compound to 5%+; treat the figure as approximate over multi-day incidents.
Why does the figure jump up so fast on minute 1?
Because the per-minute baseline rate is computed straight away, the card doesn’t ramp linearly during the first few minutes. If your store does 115; minute 2 shows $230; etc. There’s no “warm-up” smoothing. Some merchants prefer a 5-minute moving average; configure in the manifest if needed.