> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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)](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/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)](/nerve-centre/kpi-cards/woocommerce/failed-orders-24h) | The raw count behind the rate. The concrete list of orders that hit `failed` status. | | [WC Plugin Updates (Last 24h)](/nerve-centre/kpi-cards/woocommerce/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)](/nerve-centre/kpi-cards/woocommerce/revenue-at-risk-live) | Translates a high error rate into a running money figure so you can size the urgency. | | [WC SSL / HTTPS Status](/nerve-centre/kpi-cards/woocommerce/ssl-https-status) | An expired or broken certificate breaks checkout and shows up here. Rule it out quickly. | | [WC Conversion Rate](/nerve-centre/kpi-cards/woocommerce/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](/wp-admin/admin.php?page=wc-orders) filtered to the **Failed** tab shows the concrete orders behind the numerator. [WP Admin → WooCommerce → Status → Logs](/wp-admin/admin.php?page=wc-status\&tab=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](/nerve-centre/kpi-cards/woocommerce/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)](/nerve-centre/kpi-cards/woocommerce/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](/nerve-centre/kpi-cards/woocommerce/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.