> ## 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. # Revenue Drop Alert, BigCommerce > Catches a broken checkout / disconnected gateway / regional outage before the merchant notices the dashboard going quiet. How to read it, why it matters, a... **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Catches a broken checkout / disconnected gateway / regional outage before the merchant notices the dashboard going quiet. ## At a glance > Real-time alarm that fires when the rolling-hour `total_inc_tax` drops more than 25% versus the same hour over the prior 7 days. Catches a broken checkout, a disconnected gateway, or a regional outage **before the merchant notices the dashboard going quiet**. | | | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Live `SUM(total_inc_tax)` for the most recent rolling 60-minute window, compared against the average `SUM(total_inc_tax)` for the same wall-clock hour across the prior 7 days. Fires when current ≤ 75% of expected. | | **VAT / tax treatment** | **Tax-inclusive.** Both sides of the comparison use `total_inc_tax`. | | **Shipping** | Included. Standard `total_inc_tax` semantics. | | **Discounts** | Already deducted, post-discount customer-billed total. | | **Refunds** | Not deducted. Refunds happen post-fact and are not part of the live comparison. | | **`Incomplete` orders** | Included. The alert measures gross `total_inc_tax` regardless of payment-capture state. This is intentional, a sudden drop in Incomplete-creation also signals a broken checkout (no orders even being attempted). | | **Cancelled / declined orders** | Included. Same rationale, the alert measures whether orders are *being created at all*, not whether they're succeeding. Order creation stopping is a louder signal than success rate moving. | | **Currency** | Multi-currency without FX. The comparison is per-store-total, so a multi-currency store sees an aggregated alert. The alert still fires correctly because the comparison is current-week-vs-current-week (no period mismatch). | | **Channels / sources** | Not filtered. All `channel_id` values contribute. A drop concentrated in one channel is masked by healthy traffic on others; pair with [BC Alert Channel Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/channel-revenue-drop-alert) for the per-channel version. | | **7-day baseline** | The "expected" value uses the same wall-clock hour from each of the prior 7 days, then averages. This handles weekly seasonality (Tuesday 11am traffic is compared to other Tuesdays, not weekends). It does NOT handle holidays, expect false positives on Bank Holidays, Black Friday recovery weeks, and similar calendar anomalies. | | **Time window** | `RT` (real-time, evaluated each minute over a rolling 60-minute window) | | **Alert trigger** | `rolling-1h revenue drop >25% vs same hour last 7d` | | **Sentiment key** | `revenue_trend` | | **Roles** | owner, finance, marketing | ## 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 homewares brand on BigCommerce Enterprise. The 7-day rolling baseline for the 11:00-12:00 UTC hour averages $4,200 of `total_inc_tax`. On Tuesday 14 Apr 26, the live hour shows $1,580. Alert fires. | Hour | Day | Same-hour revenue | Notes | | --------------------------- | ------------- | ----------------- | --------------------------- | | 11:00 UTC | Tue 7 Apr 26 | \$4,180 | Normal | | 11:00 UTC | Wed 8 Apr 26 | \$4,420 | Normal | | 11:00 UTC | Thu 9 Apr 26 | \$4,090 | Normal | | 11:00 UTC | Fri 10 Apr 26 | \$4,540 | Normal | | 11:00 UTC | Sat 11 Apr 26 | \$3,980 | Normal | | 11:00 UTC | Sun 12 Apr 26 | \$4,210 | Normal | | 11:00 UTC | Mon 13 Apr 26 | \$4,180 | Normal | | 7-day avg | | **\$4,229** | Baseline | | **11:00 UTC Tue 14 Apr 26** | | **\$1,580** | **62.6% drop, alert FIRES** | What's interesting: 1. **The alert fires at $3,172 (75% of $4,229).** Anything below that triggers the notification. \$1,580 is well below, so the alert escalates to high-severity. 2. **Investigation sequence in the first 5 minutes**: (a) Open the BC storefront yourself in an incognito browser, can you reach checkout? (b) Try to place a test order. (c) Check BC's [status page](https://status.bigcommerce.com) for incidents. (d) Check the payment-processor status pages (Stripe, PayPal). (e) Check [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) and BC Incomplete Rate, if either spiked, the funnel is the cause. 3. **Common false-positive scenarios**: holidays, hour-of-day shifts due to daylight saving, scheduled maintenance windows the merchant forgot to silence, competitor sales pulling traffic away. **Roughly 60% of fires are real, 40% are explainable noise.** Don't treat each fire as a five-alarm event; first-pass diagnosis is fast. 4. **High-severity escalations**: a 90%+ drop (\$420 in this example) almost always means a broken checkout or a payment-vendor outage. **Skip the diagnostic dance and just verify checkout works**; if it doesn't, file a P1 with BC support and the affected gateway simultaneously. The rapid-response playbook (when this alert fires): 1. **Verify the storefront loads.** If it doesn't, BC has an outage, call BC support. 2. **Verify checkout completes** with a test card. If it doesn't, the gateway is the issue. 3. **Check payment-processor status pages** (status.stripe.com, status.paypal.com). External outages take all merchants down simultaneously; you're rarely alone. 4. **Check fraud-rule recent changes**, sudden tightening can decline meaningful traffic in minutes. Roll back any recent changes. 5. **Notify the team** via the existing #incidents Slack / Teams channel. Even false positives benefit from being acknowledged out loud. ## Sibling cards merchants should reference together | Card | Why pair it with Revenue Drop Alert | | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | [Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | The full daily / weekly trend that this alert is the real-time guardian of. | | [BC Alert Channel Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/channel-revenue-drop-alert) | Per-channel version. Catches drops concentrated in one channel that this store-wide alert masks. | | [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) | If revenue dropped *and* decline rate spiked, the gateway is the cause. | | [BC Failed Orders Count](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-count) | The combined failure pulse, useful for the first-5-minutes diagnostic. | | [BC Alert Fulfilment Delay](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert) | Often co-fires; an outage that breaks orders also delays whatever fulfilment was queued. | | [Order Count](/nerve-centre/kpi-cards/bigcommerce/total-orders) | The volume side. A revenue drop with stable order count means AOV moved (a discount went live unexpectedly). | | [BC Alert OOS Spike](/nerve-centre/kpi-cards/bigcommerce/oos-spike-alert) | A revenue drop concurrent with an OOS spike often means a top SKU went out of stock and customers abandoned. Different fix than a checkout outage. | ## Reconciling against the vendor's own dashboard **Where to look in BigCommerce Control Panel:** BigCommerce **does not surface real-time revenue alerts natively.** The BC Sales dashboard is daily-aggregation; it cannot tell you that the last hour was 60% below normal. To partially diagnose: 1. [Analytics → Sales](https://login.bigcommerce.com/deep-links/manage/analytics/in-store-conversion) shows the daily trend; today's bar will be obviously short if the alert fired earlier in the day. 2. [Orders → All orders](https://login.bigcommerce.com/deep-links/manage/orders) sorted by date descending shows the most recent orders; gaps in the timestamp sequence reveal when ordering stopped. 3. [BC Status](https://status.bigcommerce.com) for known platform issues. 4. [Settings → Payments](https://login.bigcommerce.com/deep-links/manage/payments) shows current gateway health. Other BC views that look adjacent: * **Storefront → Themes → Visit store**: lets you sanity-check the storefront loads. * **Webhooks → Recent activity**: webhook delivery health, useful when a third-party integration is the cause. **Why our alert may fire on legitimately-quiet hours:** | Reason | Direction | | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | | **Holidays not on the 7-day baseline**. Bank Holidays, US holidays not yet present in the 7-day rolling window cause false fires. | False positive | | **Daylight saving transitions**. The "same hour" calculation shifts by 1 hour twice a year; the 1-2 days after a DST flip are noisy. | False positive | | **Promotional cycles**. The day after a flash sale, hourly volume drops below the 7-day baseline (which now includes the sale spike). | False positive | | **Indexer lag**. If BC's API rate-limited during the comparison hour, our index may be undercounting. | False positive (resolves at next sync) | | **Genuine outage / broken checkout**. The intended trigger. | True positive | **Cross-connector reconciliation (when payment processors and analytics are connected):** | Card | Expected relationship | What causes legitimate divergence | | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_total_revenue`](/nerve-centre/kpi-cards/stripe/total-charge-volume) | Stripe-side hourly revenue should drop in lockstep if Stripe is the BC processor | Stripe sees only successfully captured charges; this card includes Incomplete and Declined gross. A 25% drop here may show as a 35% drop on Stripe if declines spiked. | | [`google_analytics.ga_revenue_trend`](/nerve-centre/kpi-cards/google-analytics/revenue-trend) | GA4 hourly revenue should drop in lockstep, modulo tracking gap | GA4 misses 10-25% of orders; the GA4 number is noisier than this card. | | [`paypal.pp_total_volume`](/nerve-centre/paypal/pp_total_volume) | PayPal-side hourly should drop in lockstep if PayPal is the affected gateway | PayPal-only outages show as drops on PayPal but not on Stripe; cross-checking pinpoints the broken processor. | **The real-time revenue-drop alert shape is BC-aligned with similar alerts on Shopify and Adobe Commerce; the implementation differs but the merchant-facing semantics are equivalent.** ***
Same-metric documentation cross-reference (for agencies running multiple platforms) * [`shopify.alert_revenue_drop`](/nerve-centre/shopify/alert_revenue_drop) (planned) * [`adobe_commerce.alert_revenue_drop`](/nerve-centre/adobe_commerce/alert_revenue_drop) (planned)
## Known limitations / merchant FAQs **The alert just fired, what do I do in the first 5 minutes?** Run the diagnostic sequence: (1) **Open your storefront in incognito**, does it load? (2) **Try to place a test order** through to payment. (3) **Check [BC Status](https://status.bigcommerce.com)** for known platform issues. (4) **Check your payment-processor status pages** (Stripe, PayPal, Adyen). (5) **Check for recent fraud-rule changes** that might be blocking traffic. If steps 1-2 succeed and 3-4 are clean, you likely have a false positive; check the holiday-calendar reasons in the reconcile section above. **My alert fires every Monday at 9 AM, why?** Almost always a calendar effect. Your 7-day rolling baseline includes the prior Saturday and Sunday, which have low Monday-9-AM-equivalent traffic; the average is dragged down by the weekend. When real Monday traffic hits, it's compared against that low baseline, and *normal* traffic looks like a *spike*, but the inverse can also happen if your weekend is high-volume. **Tune the baseline to "same day-of-week last 4 weeks"** rather than rolling 7 days for stores with strong weekly seasonality; the Vortex Mind alert configuration supports this option. **The alert fired but my BC Sales dashboard looks fine, who's right?** This card is right; the BC Sales dashboard is daily-aggregated and doesn't show hourly drops. By the time the daily total catches up, it's tomorrow morning and the damage is done. **The whole point of this card is to catch problems hours before the daily dashboard reflects them.** **Should I forward this alert to the engineering team or the marketing team?** **Engineering first, marketing as a CC.** A 25%+ hourly drop is almost always a technical problem (broken checkout, gateway down, fraud-rule misconfig), not a marketing problem. Marketing should be aware so they don't spend the day puzzled by sudden conversion-rate dips, but the action lever sits with engineering / operations. **Why is the threshold 25% and not 10%?** A 10% threshold fires constantly on legitimate noise (a slow lunch hour, a quiet morning). 25% is the sweet spot, large enough to almost certainly be a real signal, small enough to catch problems before they cost a full day of revenue. **Don't lower it below 20%** unless you have a high-volume, low-variance store where 10-20% drops are genuinely abnormal. **Multi-currency stores, does this alert work correctly?** Yes, with a caveat. The comparison is current-week-vs-current-week with no FX conversion, so the alert math is internally consistent (apples to apples). However, a multi-currency store that has heavy concentration in one currency may see false positives when *that one currency's* hourly traffic dips for reasons unrelated to checkout health (e.g. UK Bank Holiday). Configure per-currency alerts via the Vortex Mind alert engine for multi-currency stores. **Can I silence the alert during planned maintenance?** Yes. The Vortex Mind alert engine supports scheduled silences (e.g. "silence revenue-drop alerts every Tue 3-4 AM UTC for batch maintenance"). Configure under *Settings → Alerts → Silence windows*. Don't blanket-silence outside known maintenance, the false-positive cost is low compared to a genuine outage going unnoticed. **My store has very low order volume (5-20 orders/hour), do I get false positives constantly?** Possibly. With small denominators a single $400 order moves the hourly total by 20%+, so the drop comparison is volatile. For low-volume stores configure the alert to use a 4-hour rolling window instead of 1-hour (more stable signal), or set a minimum-baseline filter ("only fire if 7-day average for this hour is >$X"). The Vortex Mind alert configuration supports both options. **The alert never fires, am I configured correctly?** Possibly, possibly not. Verify by temporarily disabling your storefront for 5 minutes (off-peak, with team awareness) and waiting for the next minute-level evaluation. If the alert doesn't fire after 10 minutes of zero orders, the configuration has a problem; contact Vortex IQ support. **Most stores see the alert fire 0-2 times per month under normal conditions.** **Does the alert account for time zones?** The "same hour" comparison uses UTC throughout. For stores with strong local-time seasonality (e.g. UK lunchtime peak ≠ US lunchtime peak), the UTC-based comparison still works because it compares same-UTC-hour to same-UTC-hour. The alert does NOT need to know your local timezone; it cares only about the relative hourly pattern. *** ### Tracked live in Vortex IQ Nerve Centre *Revenue Drop Alert* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce 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.