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.
| What it counts | Rolling-1h COUNT(orders WHERE status = 'failed') / COUNT(orders WHERE status IN ('completed', 'processing', 'failed', 'cancelled')) x 100. Fires when this rate >5% AND >2σ above the 7D baseline. |
| REST API endpoint | Polled from /wp-json/wc/v3/orders every 10 minutes; alert engine evaluates rolling 1-hour windows. |
| VAT / tax / shipping / discounts | Not applicable, count-based alert. |
| Status filter | Numerator: failed only. Denominator: payment-attempt orders (completed + processing + failed + cancelled). Excludes pending (no attempt) and on-hold (offline payment). |
| Refunds / cancelled / failed orders | Cancelled is in the denominator; failed is the numerator. |
| Currency | Currency-agnostic. |
| Channels / sources | All web checkout. POS plugin orders rarely fail. |
| Self-hosted vs managed-Woo | Self-hosted on flaky hosting can trip the alert during host slowdowns (checkout timeouts produce failed rows). Managed-Woo rarely false-positives this way. |
| Time window | RT (rolling-1h evaluation, polled every 10 min) |
| Alert trigger | rolling-1h failed-order rate >5% AND >2σ vs 7D baseline |
| Roles | owner, operations, finance |
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.| Hour bucket | failed count | completed + processing | Rate | Alert? |
|---|---|---|---|---|
| 13:00-13:59 (baseline) | 1 | 142 | 0.7% | No |
| 14:00-14:59 (event) | 38 | 92 | 29.3% | YES |
- 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
| Card | Why pair it with this alert |
|---|---|
| WC Failed Order Rate | The underlying rate. Use to see history before the alert fired. |
| WC Total Orders | Sample size context, low-volume stores trip 5% on 1 failure. |
| WC Payment Methods | Identifies which gateway is failing. |
| WC Conversion Rate | Often dips before the alert fires. |
| Stripe Decline Rate | Stripe-side view of the same failures, useful for root-causing. |
| BC Failed Orders Count | Cross-platform peer. |
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:
| Reason | Direction |
|---|---|
| Time-zone. Alert evaluated UTC; WP Admin shows WP-site timezone. The hour-bucket may not align with merchant view. | Both report the same events |
| Self-hosted server uptime. A brief slowdown produces a transient spike. | Self-resolves; alert auto-clears |
Plugin-version compatibility. Gateway plugin update can briefly mis-set failed then correct itself. | Self-resolves |
Currency plugin. Currency switch mid-checkout can produce spurious failed rows. | Investigate per-merchant |
| Card | Expected relationship |
|---|---|
stripe.stripe_decline_rate | Stripe rate confirms whether the issue is gateway-side or Woo-side. If Stripe is calm and Woo is spiking, the issue is the WC Stripe Gateway plugin or the host. |
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 alert sensitivity?
- 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.