Cancellation Rate for the selected period.
At a glance
The percentage of orders that ended up in cancelled status over the window. It divides cancelled orders by total orders, giving you a clean read on how often a started order is being called off, by the customer, by you, or automatically by WooCommerce. A creeping cancellation rate usually points at payment friction, stock problems, or a fulfilment delay long enough that customers give up.
| What it counts | cancelled orders / total orders over the period, expressed as a percentage. The numerator is orders whose status is cancelled; the denominator is all orders created in the window across every status. |
| REST API endpoint | GET /wp-json/wc/v3/orders?status=cancelled for the numerator and GET /wp-json/wc/v3/orders for the denominator. Field used: order status and date_created_gmt. |
| Status treatment | The numerator is strictly the cancelled status. This is distinct from refunded (a paid order sent back) and from failed (a checkout that never completed payment). A cancellation is an order that was placed and then called off before fulfilment, often before payment was captured. |
| Who cancels | WooCommerce moves an order to cancelled when the customer cancels (where enabled), when an admin cancels it, or automatically via the “Hold stock” setting, which cancels unpaid pending / on-hold orders after a set number of minutes to release reserved inventory. The card does not distinguish the cause; see siblings to triangulate it. |
| Refunds vs cancellations | A cancelled order typically carries no captured payment, whereas a refunded order was paid and returned. Do not read this card as a returns metric, use Refund Rate for that. |
| HPOS vs legacy storage | Consistent whether the store runs High-Performance Order Storage (HPOS) or legacy post-meta storage; the REST API abstracts both. |
| Self-hosted vs managed-Woo | Identical across self-hosted LAMP, WordPress.com Business and Commerce plans, and managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta). |
| Time window | 30D vsP (rolling 30-day rate compared against the prior 30 days) |
| Alert trigger | >3%, driven by sentiment_key: wc_cancellation_rate |
| Roles | owner, operations |
Calculation
Calculated automatically from your WooCommerce 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 self-hosted WooCommerce homeware store with BACS enabled and the “Hold stock” setting at 60 minutes. The 30-day window covers 14 Mar 26 to 12 Apr 26.| Status | Order count | Counts in numerator? | Counts in denominator? |
|---|---|---|---|
completed | 1,420 | No | Yes |
processing | 210 | No | Yes |
on-hold | 64 | No | Yes |
pending | 90 | No | Yes |
cancelled | 58 | Yes | Yes |
refunded | 17 | No | Yes |
failed | 41 | No | Yes |
| Totals | 1,900 | 58 | 1,900 |
- 3.05% just clears the alert line. The trigger is
>3%, so this store has tipped into alert territory. Worth investigating, but the cause matters more than the number, the next three points are how you find it. - Auto-cancellation from “Hold stock” inflates the count. With BACS enabled and a 60-minute hold, every unpaid bank-transfer order that does not pay within the hour is auto-cancelled to release stock. If a chunk of these 58 are BACS timeouts rather than real customer cancellations, the rate is really telling you about payment-method friction. Cross-check On-Hold Orders for the BACS backlog.
- Cancellations are not refunds. None of the 17
refundedorders count here, and none of the 41failedcheckouts do either. Keep the three concepts separate: failed means payment never completed, cancelled means the order was called off, refunded means a paid order came back. Conflating them double-counts your problem. - A fulfilment backlog drives customer cancellations. If Order Processing Backlog was firing during this window, slow dispatch likely pushed some customers to cancel. A cancellation spike that trails a backlog spike is a strong cause-and-effect signal.
Sibling cards merchants should reference together
| Card | Why pair it with Cancellation Rate |
|---|---|
| WC Refund Rate | The paid-and-returned counterpart. Cancelled means called off before payment; refunded means money came back. Watch both for the full leakage picture. |
| WC Failed Order Rate | Failed checkouts (payment never completed) are a different problem from cancellations but often share a root cause in payment friction. |
| WC On-Hold Orders | BACS / cheque orders that time out get auto-cancelled. A high on-hold pile feeding cancellations means payment-method friction, not lost demand. |
| WC Order Processing Backlog | Slow fulfilment makes customers cancel. A cancellation spike trailing a backlog spike is cause and effect. |
| WC Orders by Status | The full status breakdown so you can see cancellations in context against every other state. |
| WC Total Orders | The denominator. A stable rate on rising orders is fine; a rising rate on flat orders is a process problem. |
Reconciling against WooCommerce
Where to look in WooCommerce Admin: WP Admin → WooCommerce → Orders and click the Cancelled filter tab; the parenthetical count is your raw cancelled total. For the rate, compare it against the all-orders count over the same window. WP Admin → WooCommerce → Reports → Orders gives historical order counts by status to sanity-check the denominator. Other WP Admin views that relate but are not the same:- Orders → Cancelled tab count: the raw numerator only, with no rate and no window control beyond the order-list filters.
- WooCommerce → Settings → Products → Inventory → “Hold stock (minutes)”: the setting that auto-cancels unpaid orders. If this is short, expect a higher cancellation rate from BACS / manual-payment timeouts.
- A subscriptions plugin’s cancellation report: subscription cancellations are a different concept from order cancellations and live in the plugin, not in
wc/v3/ordersstatus.
| Reason | Direction of divergence |
|---|---|
| Window and denominator. WP Admin shows a raw cancelled count; this card divides by all orders in a rolling 30-day window. Match both the window and the denominator before comparing. | Different framing |
| Timezone. Order timestamps use WP site timezone; this card windows in UTC. Day-boundary orders shift sides. | +/- around midnight |
| Auto-cancellation timing. The “Hold stock” job cancels unpaid orders on a schedule; the exact moment can fall either side of a window edge. | +/- a few orders at the boundary |
| Self-hosted sync lag. If the host was unreachable during a poll, recently cancelled orders may register late. | Ours temporarily lower; self-resolves |
Subscription cancellations. Subscription-plugin cancellations are not order-status cancelled and are excluded here. | Ours lower than a subscription store’s own churn report |
Known limitations / merchant FAQs
What is the difference between cancelled, failed, and refunded? Three distinct WooCommerce statuses.failed means the customer started checkout but payment never completed (declined card, gateway error). cancelled means an order was placed and then called off before fulfilment, usually before payment was captured. refunded means a paid order was sent back and money returned. This card counts only cancelled. Keep them separate; conflating them overstates your real problem.
Why is my rate high when customers say they did not cancel anything?
Most likely the WooCommerce “Hold stock (minutes)” setting is auto-cancelling unpaid orders. With BACS, cheque, or any manual payment method, an order that is not paid within the hold window is automatically cancelled to free up reserved stock. Those show as cancelled even though no human pressed cancel. Lengthen the hold window or review your payment-method mix if this is inflating the rate.
Does this include subscription cancellations?
No. WooCommerce Subscriptions tracks subscription cancellations in its own data, not as an order-status change to cancelled. This card reads order status from wc/v3/orders, so recurring-subscription churn does not appear here. Use your subscriptions plugin’s report for that.
The alert fires above 3%, is that the right benchmark?
>3% is a reasonable default for most stores. What matters more is the trend and the cause. A steady 3.5% from BACS auto-cancellations is a payment-method choice; a rate climbing from 1% to 3% over a few weeks is a real signal worth chasing. If your business model runs structurally higher (for example, made-to-order with frequent changes), contact support@vortexiq.ai about a custom threshold.
Can I bring the rate down?
Usually yes, by attacking the cause. Reduce BACS / manual-payment timeouts by lengthening the hold window or steering customers to instant payment. Cut fulfilment delays so fewer customers cancel out of impatience (watch Order Processing Backlog). Tighten stock accuracy so you are not cancelling orders you cannot fulfil.
Why does my number differ from my WP Admin cancelled count?
The Admin tab shows a raw count; this card shows a rate over a rolling 30-day window computed in UTC. Match the window, the denominator, and the timezone before concluding there is a discrepancy. For a 30-day window the timezone gap should be well under 1%.