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.
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.
The card reads 23, well above the
>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
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.
WooCommerce does not publish a “failed orders” KPI of its own, so the cleanest reconciliation is against the gateway dashboard. Counts should align closely once timezone and gateway-status behaviour are accounted for.
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 Alert Rules tab so the alert reflects your own normal day.