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.
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 Key Metric alert.
Four things to notice:
- 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
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.
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.