Sudden burst of status=failed orders, gateway outage, fraud-rule misfire, or 3DS breakage. Check the payment gateway plugin first.
At a glance
Real-time alert that fires when failed-order rate spikes. Vortex IQ’s first canary for gateway outage, fraud-rule misfire, or 3DS breakage on a Woo store.
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 US homewares brand on managed-Woo, normal failure rate ~0.6%. Tuesday 9 Apr 26, 14:20 UTC.
The card fires at 14:20 with payload “WC failed-order rate 29.3% rolling-1h, 41x baseline”. Three observations:
- The cause was a Stripe Radar tuning regression. A new fraud rule pushed by Stripe at 14:08 UTC blocked legitimate UK debit cards with a high false-positive rate. The merchant rolled back the rule by 14:55 UTC; rate returned to baseline within 90 minutes.
- Self-hosted Woo would have looked similar but with a different cause. On flaky shared hosting, a 5-minute server slowdown can produce the same alert pattern. Managed-Woo (this brand) ruled that out; on self-hosted Bluehost the merchant would also need to check the host status page.
- Plugin-induced data shape variance: the alert depends on the gateway plugin setting
failed. WC Stripe Gateway setsfailedcorrectly. PayPal Standard does not, so a PayPal-only store would NOT trip this alert during a similar gateway outage, instead orders would pile up inpending. Use Payment Methods to confirm gateway mix.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in WooCommerce Admin: WP Admin → WooCommerce → Orders, filtered to statusfailed. For real-time gateway diagnostics, the Stripe Dashboard (or PayPal Activity, etc.) is the source of truth.
Why our alert may fire when the merchant sees nothing wrong:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Self-hosted vs managed-Woo, which is more prone to false alerts? Self-hosted Woo on shared hosting can produce transient spikes during traffic surges or noisy-neighbour events. The 2σ baseline filter catches most noise, but it is worth knowing your host pattern. Status-filter selection, why this set? The denominator is “real attempts that called the gateway”, which excludespending (cart skeleton) and on-hold (offline payment). A failed-rate alert on the wrong denominator either over-fires or under-fires.
Refund-object accounting, does it affect this alert?
No, refunds are post-payment.
Plugin-induced data shape variance, what plugins affect how reliably this alert fires?
- WC Stripe Gateway: sets
failedreliably, alert is well-calibrated. - PayPal Standard: rarely sets
failed, the alert may not fire during a PayPal outage. Use Total Orders drop alerts instead. - Custom gateway plugins: behaviour varies; verify with a test transaction.
failed spike, the issue is between the gateway and Woo, host slowness, plugin regression, or webhook misfire.
Today is jumpy, why?
Rolling-1h evaluation smooths most noise, but a 30-minute traffic surge can trip the alert for one window then auto-clear.
Sync-lag from self-hosted server slowness, can it cause false alerts?
Yes, if the indexer skipped a window then catches up. The alert engine de-duplicates same-cause alerts within 30 min to mitigate.
My WP Admin shows fewer failures than the alert, debug:
- Confirm timezone alignment (UTC vs WP-site).
- Check whether the gateway plugin is correctly setting
failed. - Cross-check the gateway provider’s dashboard.
- If gap persists, contact support.