Checkout Error Rate (24h), WooCommerce

Checkout Error Rate (24h). The share of checkout attempts that failed over the last 24 hours on your WooCommerce store. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Ecommerce Platform

Checkout Error Rate (24h) for the selected period.

At a glance

The percentage of checkout attempts over the trailing 24 hours that ended in failure rather than a placed order. It is your store’s real-time conversion-killer gauge: when checkout breaks, this number climbs before your revenue charts do. It divides failed checkouts by total checkout attempts across the rolling day, surfacing payment-gateway problems, plugin conflicts, and server faults the moment they start costing sales.

What it counts	failed checkouts / total checkout attempts over the rolling 24-hour window, as a percentage. Failed checkouts are derived from orders landing in failed status (payment declined, gateway error, fatal error during order creation) against the volume of checkout attempts.
REST API endpoint	Derived from GET /wp-json/wc/v3/orders?status=failed against total order-creation attempts in the window, supplemented by REST API health signals from the indexer’s polls of wc/v3/orders. Field used: order status and date_created_gmt.
Status treatment	failed is the canonical WooCommerce status for a checkout that started but did not complete payment. It is distinct from cancelled (order called off) and refunded (paid order returned). A failed order means the customer tried to buy and could not.
Common causes	Payment-gateway declines and outages, expired or misconfigured SSL, a plugin or theme update breaking the checkout flow, PHP fatal errors, and address or tax-calculation failures. The card shows the rate; the siblings help you find which.
Gauge unit	A percentage, rendered as a gauge. The alert watches the upper end. A healthy store typically sits near 1% or below.
HPOS vs legacy storage	Consistent whether the store runs High-Performance Order Storage (HPOS) or legacy post-meta storage; the REST API abstracts both.
Self-hosted vs managed-Woo	Self-hosted stores see this card spike more often because they bear the brunt of bad plugin updates and shared-hosting resource limits. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) are steadier but not immune.
Time window	24H (rolling 24-hour rate)
Alert trigger	>2%, driven by sentiment_key: wc_checkout_error_rate_24h
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.6 fashion store with the Stripe Gateway and PayPal both enabled. The team checks the gauge on the morning of 14 Mar 26 after a quiet weekend.

24h window	Checkout attempts	Failed checkouts	Checkout error rate	Gauge state
11 Mar 26 (baseline)	1,180	11	0.9%	Healthy
12 Mar 26 (Stripe brief outage)	1,090	41	3.8%	ALERT
13 Mar 26 (PayPal still up, Stripe recovered)	1,150	14	1.2%	Healthy
14 Mar 26 (theme update at 02:00)	1,210	58	4.8%	ALERT

Four things to notice:

1. 0.9% is the healthy baseline. Some checkout failures are normal: genuinely declined cards, customers fat-fingering details, expired cards. Under the >2% trigger the gauge stays green. The alert is calibrated to catch problems above the natural noise floor.
2. The 12 Mar spike was a gateway outage. Stripe had a brief disruption and the rate jumped to 3.8%. Crucially, because PayPal stayed up, customers who switched payment methods still converted, which is why the rate did not go higher. A single-gateway store would have seen a much worse number. This is the case for offering a backup gateway.
3. The 14 Mar spike was a plugin / theme update. A theme update at 02:00 broke the checkout template and pushed the rate to 4.8%. This is the most common self-hosted failure mode. Correlate the spike against Plugin Updates (Last 24h) to pin the exact change, then roll it back.
4. This gauge is the steadier sibling of the spike alert. WC REST API / Checkout Error Rate Spike fires on a sharp 1-hour breach for immediate response; this 24-hour gauge tells you whether the problem was a blip or sustained. Use the spike alert to react, this gauge to confirm the all-clear.

Sibling cards merchants should reference together

Card	Why pair it with Checkout Error Rate (24h)
WC REST API / Checkout Error Rate Spike	The real-time 1-hour alert behind this 24-hour gauge. The spike alert reacts; this gauge confirms whether it was a blip or sustained.
WC Failed Orders (24h)	The raw count behind the rate. The concrete list of orders that hit failed status.
WC Plugin Updates (Last 24h)	The number-one root cause of a checkout spike. Correlate the rate jump against the update that shipped.
WC Revenue at Risk (Live)	Translates a high error rate into a running money figure so you can size the urgency.
WC SSL / HTTPS Status	An expired or broken certificate breaks checkout and shows up here. Rule it out quickly.
WC Conversion Rate	A rising checkout error rate caps conversion. A conversion dip with no traffic change often traces straight to this card.

Reconciling against WooCommerce

Where to look in WooCommerce Admin:

WP Admin → WooCommerce → Orders filtered to the Failed tab shows the concrete orders behind the numerator. WP Admin → WooCommerce → Status → Logs holds the gateway and fatal-error logs that explain why checkouts failed. For payment-specific declines, your gateway dashboard (Stripe, PayPal) gives the decline reasons WooCommerce records as failed.

Other WP Admin views that relate but are not the same:

• Orders → Failed tab count: the raw numerator only, with no rate and no rolling-24h framing.
• WooCommerce → Status → Logs: the fatal-error and gateway logs naming the offending plugin or decline reason.
• Your gateway dashboard (Stripe / PayPal): shows declines from its own side; some declines never create a WooCommerce order at all, so the gateway count and the WooCommerce failed count can differ.

Why our number may legitimately differ from WooCommerce Admin:

Reason	Direction of divergence
Window framing. This card is a rolling-24h rate; WP Admin shows a cumulative raw count. Match the window and divide by attempts before comparing.	Different framing
Timezone. Order timestamps use WP site timezone; this card windows in UTC. The 24h boundary can sit an hour off your WP Admin day.	+/- timezone offset
Attempt counting. Some failed payment attempts never create a WooCommerce order (client-side gateway rejection), so the gateway sees more failures than WooCommerce records.	Gateway count can exceed ours
Self-hosted unreachability. If the host was down, the indexer may read the outage as a health failure and the rate can read high during the outage window.	Ours can spike during an outage
Soft-error plugins. Some plugins catch a fatal and return a soft error page, so the order never reaches failed status even though the customer could not buy.	Ours can under-count genuine failures

Known limitations / merchant FAQs

What counts as a checkout error here? Primarily orders that land in failed status: declined cards, gateway errors, payment-token failures, and fatal errors thrown while WooCommerce tries to create the order. It does not count cancelled (order called off) or refunded (paid order returned). The card is specifically about checkouts that tried and could not complete.

Is some level of error rate normal? Yes. Genuine card declines, expired cards, and customer mistakes mean a healthy store still sits around or below 1%. The >2% alert is set above that natural floor so it catches real problems, gateway outages, plugin breakage, server faults, rather than the everyday noise of declined cards.

How is this different from the spike alert? WC REST API / Checkout Error Rate Spike evaluates a sharp 1-hour window and fires fast for immediate response. This gauge is the rolling 24-hour view: it tells you whether a spike was a momentary blip or a sustained problem, and whether you are genuinely back to normal after a fix. Use them together.

My gateway dashboard shows more declines than this card, why? Some payment failures are rejected client-side by the gateway before WooCommerce ever creates an order, so they never reach failed status and never enter this card’s numerator. Your Stripe or PayPal dashboard sees those; WooCommerce does not. The gateway count being higher is expected and usually not a problem.

The rate spiked overnight, where do I start? Check Plugin Updates (Last 24h) first, an unattended plugin or theme update breaking checkout is the most common cause. Then read WooCommerce → Status → Logs for fatal errors, and confirm your SSL certificate is valid via SSL / HTTPS Status. If the failures cluster on one gateway, check that gateway’s status page.

Does this work the same on managed Woo as self-hosted? The calculation is identical. In practice self-hosted stores spike this card more often because they carry the risk of bad plugin updates, PHP-version drift, and shared-hosting limits. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) reduce the server-fault class but cannot stop a checkout-breaking plugin update or a gateway outage.

Why is my 24h boundary an hour off from WP Admin? This card windows in UTC; WooCommerce timestamps use your WP site timezone. The rolling-24h cutoff therefore sits at a fixed offset from your local day. Align the two before concluding the timing is wrong.

---

Tracked live in Vortex IQ Nerve Centre

Checkout Error Rate (24h) is one of hundreds of KPI pulses Vortex IQ tracks across WooCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.