At a glance
Daily count and value of cancelled Adobe Commerce orders over the trailing 90 days. The trend view of Cancellation Rate. Useful for visualising whether a cancellation spike is a one-day anomaly, a sustained 7-to-14-day issue, or a structural change. The 90-day window catches monthly seasonality (end-of-month B2B PO restructuring, payday cycle effects) that a 30-day window would miss.
| What it counts | Per-day: COUNT(orders where state = canceled AND date(updated_at) = day) and SUM(grand_total) of those orders. Each day is one bucket. The card returns a 90-element series. |
| API field | state, updated_at, grand_total from GET /rest/V1/orders. The card uses updated_at rather than created_at because the cancellation event is what’s being measured, not the original purchase. |
| VAT / tax treatment | The value series uses grand_total (tax-inclusive on B2C, often exempt on B2B). The count series is tax-irrelevant. |
| Shipping inclusion | Included in the value series via grand_total. |
| Discounts | Deducted in the value series. |
| Credit Memo refund treatment | Not relevant; this card tracks cancellations (pre-shipment), not Credit Memos (post-shipment). |
state machine inclusion | Numerator: state = canceled only. Includes auto-cancelled pending_payment timeouts. |
pending_payment quirk | When pending_payment orders auto-cancel after 24h timeout, the cancellation event registers on the day of timeout (not on the day of original order create). This can create a 1-day-lag pattern in the chart. |
Multi-currency grand_total vs base_grand_total | Value series uses base_grand_total for cross-currency rollup. |
Store View scope (store_id) | All Store Views by default. Per-Store-View overlays useful for spotting a regional pattern. |
| Time window | 90D. |
| Alert trigger | None by default; this is a trend visualisation. Pair with Cancellation Rate for alerting. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Adobe Commerce 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 nutritional supplements brand on Adobe Commerce 2.4.6 with US, UK, and B2B Store Views. Window: 90 days ending Monday 4 May 26. 90-day cancellation overview:| Metric | Value |
|---|---|
| Total cancelled orders | 387 |
Total base_grand_total of cancelled | $58,400 |
| Average daily cancellations | 4.3 |
| Standard deviation | 1.8 |
| Largest daily count | 31 |
| Date | Daily cancel count | Cause (per investigation) |
|---|---|---|
| 8 Feb 26 | 22 | Stripe webhook outage during Super Bowl traffic (47 orders went to pending_payment, 22 timed out) |
| 14 Mar 26 | 31 | Fraud rule false positive (auto-cancelled 28 legitimate orders flagged as fraud) |
| 22 Apr 26 | 18 | UK warehouse stock recount, 18 orders cancelled because of physical-vs-system stock mismatch |
- Three distinct causes, none repeating: gateway, fraud rule, ops correction. None is a recurring pattern.
- The fraud rule spike (31 cancels in one day) would not have triggered the Cancellation Rate alert on its own (one bad day in a 30-day window dilutes; 31/130 = 24%, way over the 3% trigger, but the next day the rate dropped back). The trend view makes the day visible.
- Median daily cancel count (3) reflects baseline
pending_paymenttimeouts and routine ops actions; nothing alarming. - Cumulative value at risk over 90 days: $58,400 of orders cancelled. About half is timeout-driven (recoverable if customers retry, many do), about a quarter is fraud rule (false-positive cost), about a quarter is OOS-at-picking and other ops causes.
- Strategic takeaway: investing in (a) webhook resilience (timeout reduction) and (b) fraud-rule false-positive tuning would together save ~$30k of unrecovered revenue per quarter.
- Cross-checking Cancelled-Over-Time against Stripe webhook delivery success rate: the Feb 8 spike correlates within the hour. Confirms diagnosis.
- B2B portal contributed 4 cancellations across the entire 90 days. B2B is steady at near-zero, as expected. The signal is concentrated in the consumer Store Views.
Sibling cards merchants should reference together
| Card | Why pair it with Cancelled Over Time |
|---|---|
| Cancellation Rate | The single-number summary; this card is its trend chart. |
| Order State Distribution | The decomposition: canceled is one state of seven. |
| Refunds Over Time | Sister chart for post-shipment refunds. The two together show full money-back trend. |
| Refund-Rate Spike Alert | Spike-alert pair for the post-shipment side. |
| Daily Order Trends | The full-volume context. Cancellations as % of daily orders is more informative than absolute count on volatile days. |
| Total Revenue | The denominator-of-context for value at risk. |
stripe.stripe_webhook_health | Webhook outages drive timeout cancels. The strongest correlator. |
shopify.cancelled_over_time | Cross-platform peer. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Sales > Orders filtered by Status = “Canceled” with date range = “Last 90 Days”. The Admin grid lists individual orders; you can group by date manually via export-and-pivot for the daily series.
Reports > Sales > Orders with date range. The Admin report includes cancelled orders by default but does not chart them as a separate series.For the cancellation cause:
Sales > Orders > [Order ID] > Comments has the auto-generated note for timeout cancels and the operator note for manual cancels.Why our number may legitimately differ from a manual Admin computation:
| Reason | Direction of divergence |
|---|---|
Day-bucket using updated_at. The card buckets cancellations by the day of state-transition. Admin’s order-list filter shows by created_at. A pending_payment order created on day 1 that times out on day 2 appears on day 1 in Admin’s list but day 2 in this chart. | Up to 1-day lag between admin and card |
| Time-zone. Admin in Store View timezone; card UTC. Day boundaries shift. | ±1 day on bucket assignment |
Currency. Value series uses base_grand_total. Admin shows in Store View base currency. | Material on multi-currency |
status rename. If Admin uses a custom status mapped to the canonical canceled state, both should match. Custom workflows that bypass state would not. | Material if non-standard workflow |
| Pair | Expected relationship | What divergence tells you |
|---|---|---|
stripe.stripe_webhook_health | Webhook failure spikes precede cancellation spikes by ~24h | A near-perfect correlation; the strongest diagnostic pair. |
stripe.stripe_payment_decline_rate | Decline-rate spikes drive pending_payment timeout cancels | Another strong correlator. |
| Customer service ticket volume | Spikes correlate with customer-initiated cancels | Cancellation spike + flat ticket volume = automated/timeout, not customer choice. |
Known limitations / merchant FAQs
Why does the chart bucket byupdated_at rather than created_at?
The cancellation event is what we’re measuring; updated_at reflects when the cancellation happened. A pending_payment order created on Monday that times out on Tuesday morning is a Tuesday cancellation event. Bucketing by created_at would assign it to Monday and conflate the order-creation pattern with the cancellation pattern.
Why use a 90-day window rather than 30?
Cancellation patterns often have monthly seasonality (B2B end-of-month PO restructuring, payday-cycle fraud campaigns, monthly stock counts triggering OOS-at-picking). 90 days catches three monthly cycles, enough to spot recurring patterns. 30 days is too short to distinguish “monthly recurring” from “one-off”.
Adobe Commerce vs Magento Open Source: difference?
None at the calculation. Adobe Commerce paid edition’s B2B Companies module adds approval-flow cancels (an order rejected by a Company approver moves to canceled); these appear in the chart but are typically rare. Open Source merchants without the B2B module don’t see this cause.
My multi-store Adobe Commerce, can I overlay Store Views on the same chart?
Yes, configure per-Store-View series in the manifest. Useful for spotting region-specific spikes (a UK warehouse stock-recount that doesn’t affect US, for example).
The chart shows a steady decline in cancellations, is that real progress?
Probably yes if it’s been sustained for 30+ days. Common drivers of declining cancellation: gateway-callback hardening (fewer timeout cancels), fraud-rule tuning (fewer false positives), MSI reservation-window adjustments (fewer OOS-at-picking). All three are operational maturity wins worth attributing.
Why doesn’t this card show abandoned carts?
Abandoned carts are quotes that never became orders; cancelled orders are orders that were created and then cancelled. They’re different funnel stages tracked by different tables in Adobe (quote vs sales_order). For cart abandonment trend, see Cart-Abandonment Spike Alert.
A spike on a single day, should I worry?
Not necessarily. Single-day spikes are usually one-off (a webhook burst failure, a fraud-rule tuning incident, a stock-recount). Sustained 7+ day elevation is the worry signal. The chart’s value is showing the difference between “yesterday was bad” and “the last fortnight is bad”.