Status=failed signals checkout/payment-gateway issues. Spike often correlates with plugin update or theme change.
At a glance
The count of WooCommerce orders that hitfailedstatus in the rolling last 24 hours.failedis the status WC sets when a payment gateway returns an error or the checkout flow times out before payment captures. A sudden rise is the earliest visible symptom of a broken checkout, often within hours of a plugin update or theme change.
| What it counts | COUNT(orders WHERE status = 'failed') over the last 24 hours. Each declined or errored payment attempt is one order row in WooCommerce. |
| REST API endpoint | GET /wp-json/wc/v3/orders?status=failed. WooCommerce stores failed as a first-class order status (wc-failed), so this is a direct status filter, not a derived calculation. |
| What “failed” means in WC | The gateway attempted to charge and the charge did not succeed: card declined, 3DS challenge timed out, gateway returned an API error, or the synchronous checkout request timed out on a slow server before the callback completed. Distinct from pending (no payment attempted) and on-hold (awaiting offline payment like BACS). |
| Status filter | Numerator is failed only. This is a raw count, not a rate; for the ratio view see Failed Order Rate. |
| Gateway dependence | Whether an attempt lands in failed depends on the gateway plugin. The WC Stripe Gateway and Authorize.Net set failed reliably. PayPal Standard often leaves declines in pending. So this card reflects the failure modes of your specific gateway mix. |
| Self-hosted vs managed-Woo | Same definition everywhere. Self-hosted Woo on shared hosting (Bluehost, GoDaddy) shows structurally higher failed counts because slow servers cause checkout timeouts. Managed-Woo (Woo.com Cloud, WP Engine, Pressable, Kinsta) typically runs much lower. |
| Time window | 24H (rolling last 24 hours) |
| Alert trigger | >5, driven by sentiment_key: wc_failed_orders_24h |
| Roles | owner, operations, engineering |
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 UK outdoor-gear brand on self-hosted WooCommerce 8.6 with the Stripe Gateway plugin and 3DS Strong Customer Authentication enforced. The store owner pushed a theme update on the evening of 17 Jun 26. The 24-hour window runs 17 Jun 26 18:00 UTC to 18 Jun 26 18:00 UTC.| Hour block (UTC) | Failed orders | Note |
|---|---|---|
| 18:00 to 22:00 (17 Jun 26) | 1 | Normal baseline (one declined card) |
| 22:00 to 02:00 | 7 | Theme update deployed 21:50; checkout JS broke |
| 02:00 to 10:00 | 11 | Overnight orders failing silently |
| 10:00 to 18:00 (18 Jun 26) | 4 | Merchant noticed, partial rollback |
| Failed Orders (24h) | 23 |
>5 threshold, so Vortex IQ Nerve Centre raises an alert. Four things to notice:
- The spike tracks the theme deploy almost exactly. The baseline was roughly 1 failure every 4 hours. Failures jumped immediately after the 21:50 theme update. A new theme version shipped a JavaScript bundle that conflicted with the Stripe Elements iframe, so card entry silently broke and every attempt timed out into
failed. This is the classic “spike correlates with plugin or theme change” pattern. failedis notpending. These 23 orders reached the payment step and the gateway call failed. They are different from abandoned carts (which sit inpending). That distinction is what makes afailedspike actionable: real customers tried to pay and could not.- Self-hosted timeouts amplified it. This brand’s shared host had elevated response times overnight. On a slow server, even a partly working checkout can tip card authorisations into timeout-driven
failedrows. Managed-Woo hosts rarely show this secondary effect. - The fix lived in the deploy, not in Woo. Rolling the theme back at 14:00 cut the failure rate. The debug order: check the gateway logs (Stripe Dashboard > Logs) to confirm the charges never succeeded, then correlate the spike start against your recent plugin and theme changes. Pair with Failed Order Rate for the normalised view and Checkout Error Rate (24h) for the upstream signal.
Sibling cards merchants should reference together
| Card | Why pair it with Failed Orders (24h) |
|---|---|
| WC Failed Order Rate | The normalised version. 23 failures on 2,000 orders is noise; on 60 orders it is an outage. The rate tells you which. |
| WC Failed-Order Spike Alert | The trigger card. Pairs with this count for the alert chain. |
| WC Checkout Error Rate (24h) | The upstream signal. Checkout errors precede failed orders; a rise here often shows up as a checkout-error spike first. |
| WC Payment Methods | Tells you which gateway is failing. A Stripe-specific spike looks very different from a PayPal misconfiguration. |
| WC On-Hold Orders | Companion failure mode. On-hold are payment-pending (BACS), not failed. Different fixes. |
| BC Failed Orders Count | Cross-platform peer for agencies running a multi-platform book. |
| Shopify Failed Orders Count | SaaS-platform peer. Shopify lacks a native failed status, so the semantics differ slightly, useful to contrast. |
Reconciling against WooCommerce
Where to look in WooCommerce Admin: WP Admin > WooCommerce > Orders filtered to statusfailed (the status filter tabs sit above the orders table). This gives the raw list. WooCommerce’s standard reports (/wp-admin/admin.php?page=wc-reports) deliberately skip failed entirely, so there is no built-in “failed orders today” report, which is exactly why this card exists. The authoritative cross-check is the gateway side: Stripe Dashboard > Payments > Failed, or PayPal > Activity filtered to declined.
Other WP Admin views that look related but are not:
- WP Admin > WooCommerce > Reports > Sales by date: excludes
failedfrom every figure. It will not show this count. - Home > Stats overview widget: revenue only, no failure data.
| Reason | Direction of divergence |
|---|---|
| Time-zone. WC stores order timestamps in WP-site timezone (Settings > General > Timezone); Vortex IQ runs on UTC. The “last 24h” window starts at a different wall-clock time, so boundary failures fall differently. | +/- a few orders at the window edge |
Self-hosted server uptime. A slow or unreachable WP host can produce duplicate failed rows (the customer retries) and can also delay the indexer poll. Self-hosted on shared hosting shows this most; managed hosts are steadier. | Ours higher during outages; temporarily lower if the poll was missed |
Gateway plugin behaviour. Some gateways do not set failed and leave declines in pending. PayPal Standard is the common offender. On those gateways this card under-reports actual declines. | Ours lower than gateway logs |
HPOS vs legacy storage. Order status lives in wc_orders under HPOS and in post-status under legacy storage. The REST API abstracts both, but a half-migrated store can briefly show stale status counts. | Either; self-resolves once HPOS sync completes |
Retry idempotency. A retry that succeeds the second time can leave behind a failed shell from the first attempt, inflating the count above the number of distinct customers affected. | Ours slightly higher |
Known limitations / merchant FAQs
A failed order spiked right after I changed a plugin or theme, is that a coincidence? Almost never. The single most common cause of afailed spike is a recent deploy: a plugin update that changed checkout behaviour, a theme update that broke the payment iframe, or a new caching rule that interfered with the gateway callback. When this card alerts, your first move is to list everything you changed in the last 24 to 48 hours and roll the most recent change back as a test.
Why does this card differ from my gateway dashboard?
Two reasons. First, gateway behaviour: some plugins (notably PayPal Standard) leave declines in pending instead of failed, so WC under-records what the gateway saw. Second, client-side errors: the gateway may see authorisation attempts that never create a WC order at all (for example a Stripe Elements error before submit), so the gateway can show more failures than WC. Treat the gateway log as the ground truth for “did money move”.
Does self-hosting affect this number?
Yes. On self-hosted shared hosting, a slow server can tip otherwise valid checkouts into timeout-driven failed rows, and a host outage can both inflate counts (customer retries) and delay the indexer. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) run far steadier. If your failure count spikes and the gateway shows the same cards succeeding, suspect host capacity.
Is this a count or a rate?
A count, the raw number of failed orders in the last 24 hours. Five failures matters very differently on a 60-order day than on a 2,000-order day. For the normalised view, use Failed Order Rate. The two are designed to be read together.
Some of my failed orders later succeeded, are they double-counted?
A customer who retries and succeeds leaves the original failed order shell in place plus a new successful order. WooCommerce does not merge them, so the failed shell still counts here. This is expected: it records that an attempt failed, even if a later attempt worked. If you see many such pairs, it usually points to a transient gateway or host issue rather than a hard breakage.
Can I change the alert threshold?
Yes. The >5 default is a generic baseline. High-volume stores should raise it; very low-volume stores may want it lower. Adjust per profile in the Sensitivity tab so the alert reflects your own normal day.