Checkout step now bleeding, broken shipping calc, payment gateway timeout, slow page. Live signal not lagged to morning report.
At a glance
Real-time alarm when checkout abandonment spikes above 75% AND deviates more than two standard deviations from the prior seven-day baseline. Catches a broken shipping calculator, a timed-out payment gateway, a Stencil theme regression after a deploy, or a sudden Cloudflare slowdown, before the merchant notices on the morning sales report. Where Shopify merchants get checkout-stability signals from Shop Pay’s near-uniform UX, BigCommerce merchants run more theme variation and more payment gateways, so abandonment swings are louder and need a real-time alarm.
Calculation
Calculated automatically from your BigCommerce 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 fashion retailer on BigCommerce Pro running a Stencil theme with Stripe + PayPal as gateways. Tuesday 14 Apr 26, 14:00-15:00 UTC. Same-hour 7-day baseline: 142 carts started, 51 orders completed, 64.1% abandonment.
What’s interesting:
- The 88.5% absolute rate alone wouldn’t fire on a quiet hour. A 14:00 UTC hour with only 20 carts and 17 abandoners reads 85% but is just sample noise. The dual condition (>75% AND >2σ) ensures we only fire on hours with statistically significant deviation. The z-score is doing the real work here, not the absolute threshold.
- Investigation sequence in the first 2 minutes: (a) Open the storefront in incognito, navigate to a product, add to cart, proceed to checkout, get to the shipping-rate step. (b) Did the page hang? Did the shipping rate fail to populate? Did Stripe / PayPal load correctly? (c) Check Stripe / PayPal status pages. (d) Check BC Settings → Shipping → Real-time rate connectors (UPS, USPS, FedEx, ShipperHQ); rate-API outages are the #1 cause.
- The Stripe iframe was returning 503s. Stripe’s status page confirmed a 35-minute partial outage in their US-East acquirer at 14:05-14:40 UTC. Customers saw the payment iframe fail to load, retried once, left.
- Lost revenue estimate: 156-18 = 138 abandoners on the alert hour, ~30% would have completed normally = 41 lost orders. At AOV 3,485 in one hour. The whole point of catching this in real time is to recover by switching to PayPal as the primary processor for the duration of the outage, BC’s payment settings allow swapping default gateway in under a minute.
- The mitigation actually worked. At 14:42 UTC the merchant disabled Stripe and made PayPal the default; by 15:00 the abandonment rate was still elevated (90.2%) because the outage was still resolving in customer browsers, but completion volume had normalised by 15:30. Lesson: real-time alerts buy you the option to fail over to alternative payment paths during gateway outages, but only if you’re watching.
- Run a test order yourself. Incognito browser, fresh session, complete a real (or pre-approved test) checkout. Reproduce the failure or confirm it’s intermittent.
- Check status pages: status.bigcommerce.com, status.stripe.com, status.paypal.com, your shipping-rate provider’s status (status.shippo.com, etc.).
- Check recent deploys. If a Stencil theme push went out in the last 4 hours, that’s the cause until proven otherwise; roll back.
- Check coupon validity. A recently-disabled coupon code reactivating accidentally, or a price-list with an invalid SKU, can cascade through the checkout step.
- Failover the gateway. Most BC stores have at least two payment gateways configured. Make the working one the default for the duration of the outage; revert when status pages clear.
- Notify the team via #incidents channel. Even false positives benefit from being acknowledged.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: BigCommerce does not surface a native real-time abandonment-rate alarm. The closest views are Analytics → Abandoned Carts (Plus / Pro / Enterprise) which shows a daily rollup, and Marketing → Abandoned Cart Saver which lists individual abandoned carts but not the rate. Neither updates in under 6 hours, so neither is useful during a live outage. For real-time diagnosis:- Settings → Shipping → Real-time rates shows whether the rate API is responding.
- Settings → Payments shows current gateway connection health.
- Storefront → Themes → Visit store, then complete a test checkout to reproduce.
- Webhooks → Recent activity shows webhook delivery latency and failures.
Cross-connector reconciliation (when payment processors and analytics are connected):
The real-time abandonment alert shape is BC-aligned with similar alerts on Shopify (per
checkout_token) and Adobe Commerce (per quote_id); merchant-facing semantics are equivalent across platforms.
Known limitations / merchant FAQs
The alert fired but my cart-recovery emails went out fine. Is this a false positive? Possibly not. Cart-recovery emails fire on the BCIncomplete status, which is the abandonment we’re measuring. The recovery email is the response to the abandonment, not evidence the abandonment didn’t happen. If your cart-recovery flow had a sudden burst of emails matching the alert window, that’s actually confirmation the alert is real, not refutation.
My BC abandonment dashboard says my abandonment rate is 60%, well below the 75% threshold. Why does this card alert?
Because BC’s dashboard is daily; this card is hourly. A 60% daily rate hides a 90% bad-hour and a 50% good-hour. The alert exists specifically to catch the bad hours that the daily rollup smooths over. A 90%-abandonment hour is roughly 3x as much lost revenue as a 70%-abandonment hour, even though the daily average barely moves.
My multi-storefront BC instance has six storefronts. Does the alert fire per-storefront or store-wide?
By default, per-storefront. Each storefront has its own baseline and alert. A theme regression on Storefront A doesn’t trigger an alert on Storefronts B-F. Configure store-wide aggregation under Settings → Alerts → Aggregation if you want a single alert; we recommend per-storefront for multi-brand merchants who run different themes per storefront.
Why does B2B Edition need a different baseline?
Because B2B portal abandonment is structurally higher than DTC. A 60% abandonment rate on B2B is healthy (quote-and-think cycles take 24-72 hours; “abandonment” within an hour just means the buyer is going to come back later). Applying the DTC 75% threshold to a B2B portal generates 5-10 false alarms per week. The auto-tune detects the customer-group split and applies a B2B-appropriate (typically 85% absolute, 2.5σ) threshold.
My Stripe iframe occasionally fails for a single user but the alert never fires. Why?
Because individual-user failures don’t move the rate enough to cross the threshold. The alert is designed for systemic outages (everyone affected) rather than per-user UX issues. For per-user abandonment investigation use the BC Abandonment Recovery card, which surfaces individual-cart diagnostics.
Should I forward this alert to engineering or marketing?
Engineering first, marketing CC. Most fires are technical (gateway, theme, shipping) and need engineering action. Marketing should be aware so they can pause email / ad sends pointing at a broken funnel, but the action lever is engineering. Exception: if the alert fires during a known flash-sale launch, marketing leads the response (the surge itself is causing temporary checkout congestion).
My BigCommerce store has a Headless / Storefront API frontend. Does this alert work?
Yes, if your headless frontend writes to BC’s Checkout API normally (the common pattern). The alert measures BC’s checkout webhook stream, which fires regardless of frontend. However, if your headless frontend bypasses BC’s checkout entirely (rare, but some agencies do this for speed), the cart-created webhook may not fire and the alert will under-report. Verify by completing a test order and confirming the cart/created webhook fires.
I just made the headline alert threshold tighter (>70% instead of >75%). Now I get 5 alerts a day. What gives?
75% is the floor; below 70% the noise floor is too loud. Most healthy stores baseline at 60-72% normal abandonment, so a 70% threshold sits inside the noise distribution rather than above it. If you want louder alerting, tighten the alert rule’s z-score threshold (lower the σ from 2 to 1.5) rather than the absolute floor, that catches genuine deviation while preserving the noise floor.
Can I silence the alert during a planned theme deploy?
Yes, scheduled silences under Settings → Alerts → Silence windows. We strongly recommend silencing for the 30 minutes around any theme deploy rather than relying on “the deploy is fine” assumptions. If the deploy is fine, the silence harmlessly unmutes; if the deploy breaks, you’ll see it on the next non-silenced window.
My alert fires every Monday at 9 AM. Why?
Almost certainly a calendar effect. Your 7-day baseline now includes Sunday’s low-volume hour averaged with weekday hours, depressing the expected count. When real Monday traffic hits, the absolute completion-rate may be normal but the deviation reads high. Tune to “same hour, same day-of-week, last 4 weeks” rather than rolling 7 days; the option is in Settings → Alerts → Baseline mode.