Most common WC failure mode = plugin update breaks checkout. Pair with plugin-updates-last-24h for root-cause.
At a glance
A live alarm that fires the moment your store starts losing checkouts or your REST API starts throwing server errors. It watches two signals at once: the share of attempted checkouts that fail, and the share of WooCommerce REST API responses returning 5xx. When either crosses its threshold the card escalates to the top of Nerve Centre so you can act before the lost-sales bill grows.
| What it counts | An alert list of breach events. The card surfaces the current checkout error rate and the current REST API 5xx rate, and raises an incident when either exceeds its trigger. Each row represents a detected breach window with its peak rate and affected request volume. |
| REST API endpoint | Health is inferred from polling GET /wp-json/wc/v3/ system endpoints and from the HTTP status codes returned during normal order and product polls (wc/v3/orders, wc/v3/products). Checkout failures are derived from the rate of orders landing in failed status against checkout attempts. |
| Trigger logic | Fires when checkout error rate >2% in last 1h OR REST API 5xx rate >5%. The two conditions are OR-combined, so a clean REST API can still alert on checkout failures and vice versa. The 1-hour window keeps it responsive without firing on a single stray error. |
| Polling | The Vortex IQ Woo indexer polls on a short cadence for health signals so this card stays near real time. A self-hosted host that is fully down will itself trip the 5xx / unreachable condition. |
| Status treatment | Checkout failures are read primarily from orders flipping to failed (gateway declined, fatal PHP error during order creation, payment-token error). failed is the canonical WooCommerce status for a checkout that started but did not complete payment. |
| Self-hosted vs managed-Woo | Self-hosted stores are the most common source of spikes here because checkout-breaking plugin updates, PHP memory exhaustion, and database lock contention hit them hardest. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) absorb load better but are not immune to a bad plugin update. |
| Time window | RT (real time, evaluated over a rolling 1-hour window) |
| Alert trigger | checkout error rate >2% in last 1h OR REST API 5xx rate >5%, driven by sentiment_key: wc_alert_api_failure_rate_spike |
| Roles | owner, engineering, 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 8.4 store on shared hosting auto-updates a payment-gateway plugin overnight. The update ships a fatal incompatibility with the active PHP version. The store wakes up to a Hero alert.| Time (UTC), 14 Mar 26 | Checkout attempts | Failed checkouts | Checkout error rate | REST API 5xx rate | Alert state |
|---|---|---|---|---|---|
| 06:00 to 07:00 | 84 | 1 | 1.2% | 0.3% | Quiet |
| 07:00 to 08:00 (plugin auto-update at 07:14) | 96 | 22 | 22.9% | 6.1% | FIRING |
| 08:00 to 09:00 (rollback applied 08:35) | 78 | 9 | 11.5% | 1.0% | Cooling |
| 09:00 to 10:00 | 90 | 1 | 1.1% | 0.2% | Quiet |
- Both conditions tripped at once. The bad plugin caused checkouts to fail (22.9%, well over the 2% trigger) and threw PHP fatals that surfaced as REST API 5xx (6.1%, over the 5% trigger). Either alone would have fired the card; together they confirm a server-side fault rather than a one-off gateway blip.
- The root cause was an auto-update. This is the single most common WooCommerce checkout outage pattern: an unattended plugin or theme update lands a fatal incompatibility. Pair this card with Plugin Updates (Last 24h) to correlate the spike timestamp against the exact update that shipped.
- The 1-hour window kept it honest. A single failed gateway call at 06:00 did not fire the card; it took a sustained breach across the rolling hour. This avoids alert fatigue from isolated declines while still catching a real outage within minutes.
- Lost-sales estimate. Roughly 22 + 9 = 31 failed checkouts across the incident, at the store’s ~£68 average order value, that is around £2,100 of orders at risk in under two hours. See Revenue at Risk (Live) for the running figure during an active incident.
Sibling cards merchants should reference together
| Card | Why pair it with this alert |
|---|---|
| WC Plugin Updates (Last 24h) | The number-one root cause of a checkout spike. Correlate the alert timestamp against the exact plugin or theme update that shipped. |
| WC Checkout Error Rate (24h) | The 24-hour gauge behind this real-time alert. Use it to see whether the spike was a blip or a sustained problem. |
| WC Failed Orders (24h) | The raw count of orders that hit failed status, the concrete evidence behind the checkout error rate. |
| WC Revenue at Risk (Live) | Translates the spike into a running money figure so you can prioritise the fix. |
| WC Plugin Compatibility Audit | Preventive view. A flagged incompatibility here often predicts the spike before it happens. |
| WC SSL / HTTPS Status | An expired or misconfigured certificate also breaks checkout and can surface as a spike. Rule it out fast. |
Reconciling against WooCommerce
Where to look in WooCommerce Admin: WP Admin → WooCommerce → Status for the system report, then the Logs tab to read fatal-error and gateway logs. WP Admin → WooCommerce → Orders filtered to Failed shows the concrete checkouts that died during the incident window. The site-health screen at WP Admin → Tools → Site Health flags PHP fatal errors that the alert may be reacting to. Other WP Admin views that relate to this alert:- WooCommerce → Status → Logs: the fatal-error log (
fatal-errors-*.log) usually names the offending plugin and file path. This is your fastest root-cause read. - Tools → Site Health → Info: confirms the active PHP version, which a plugin update may have outgrown.
- Your host’s error log (self-hosted): PHP 500s and memory-exhaustion entries that never reach WP Admin live here.
| Reason | Direction of divergence |
|---|---|
| Detection window. This alert evaluates a rolling 1-hour window; WP Admin order lists show cumulative counts with no time slicing. | Different framing, not directly comparable |
| Timezone. WooCommerce logs and order timestamps use WP site timezone; this card evaluates in UTC. The spike timestamp may read an hour off against WP Admin. | +/- timezone offset on the timestamp |
| Self-hosted unreachability. If the host is fully down, the indexer sees the outage as 5xx / unreachable and fires; WP Admin may be inaccessible to confirm at that moment. | Alert leads the Admin view |
Gateway-side declines vs server faults. A high failed rate from genuine card declines (fraud waves, expired cards) can fire the checkout condition without any server fault. | Checkout condition fires; 5xx stays clean |
| Plugin-suppressed errors. Some plugins catch fatals and return a soft error page (HTTP 200) so the 5xx signal stays low while checkouts still fail. | 5xx clean, checkout condition fires |
Known limitations / merchant FAQs
What is the single most common cause of this alert? A plugin or theme update that breaks checkout, usually an unattended auto-update overnight. The moment this fires, open Plugin Updates (Last 24h) and line up the update timestamps against the spike. Rolling back the offending plugin is the fastest fix; investigate the compatibility issue afterward. Why does it watch both checkout failures and REST API 5xx? They catch different failure modes. A highfailed-order rate with clean 5xx points to a payment-gateway problem (declines, token errors, gateway outage). A 5xx spike points to a server-side fault (PHP fatal, memory exhaustion, database lock). Watching both means the card fires whether the break is in your payment layer or your application layer.
Can genuine card declines trigger a false alarm?
Yes, in the sense that a fraud wave or a batch of expired cards can push the failed rate over 2% without anything being wrong with your store. Check the failed-order detail in WP Admin → Orders → Failed. If the failures are spread across gateways and customers with declined-card reasons, it is a payment pattern, not an outage. If they cluster on fatal errors, it is your store.
My store was fully down, why did the card still fire?
A total outage means the REST API is unreachable, which the indexer treats as a 5xx-class health failure, so the card fires precisely when you most need it to. It is one of the few cards that works as a true uptime alarm for self-hosted stores.
Does this work the same on managed Woo as self-hosted?
The trigger logic is identical. In practice self-hosted stores fire this card far more often because they bear the brunt of bad plugin updates, PHP-version drift, and shared-hosting resource limits. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) reduce the server-fault class but cannot prevent a checkout-breaking plugin update.
How fast does it clear after I fix the problem?
The card cools as the rolling 1-hour window moves past the breach. Once error rates fall back under threshold for a sustained period the incident closes. If it keeps re-firing after a rollback, the root cause is not the plugin you rolled back, check the fatal-error log in WooCommerce → Status → Logs again.
Why is the spike timestamp an hour off from my WP Admin logs?
This card evaluates in UTC; WooCommerce logs and order timestamps use your WP site timezone. Align the two before concluding the timing is wrong. For most debugging the offset is a fixed, known number.