Skip to main content
Card class: Hero • Category: Ecommerce Platform
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 countsLive 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 treatmentTax-inclusive. Both sides of the comparison use total_inc_tax.
ShippingIncluded. Standard total_inc_tax semantics.
DiscountsAlready deducted, post-discount customer-billed total.
RefundsNot deducted. Refunds happen post-fact and are not part of the live comparison.
Incomplete ordersIncluded. 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 ordersIncluded. 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.
CurrencyMulti-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 / sourcesNot 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 for the per-channel version.
7-day baselineThe “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 windowRT (real-time, evaluated each minute over a rolling 60-minute window)
Alert triggerrolling-1h revenue drop >25% vs same hour last 7d
Sentiment keyrevenue_trend
Rolesowner, 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,200of‘totalinctax‘.OnTuesday14Apr26,thelivehourshows4,200 of `total_inc_tax`. On Tuesday 14 Apr 26, the live hour shows 1,580. Alert fires.
HourDaySame-hour revenueNotes
11:00 UTCTue 7 Apr 26$4,180Normal
11:00 UTCWed 8 Apr 26$4,420Normal
11:00 UTCThu 9 Apr 26$4,090Normal
11:00 UTCFri 10 Apr 26$4,540Normal
11:00 UTCSat 11 Apr 26$3,980Normal
11:00 UTCSun 12 Apr 26$4,210Normal
11:00 UTCMon 13 Apr 26$4,180Normal
7-day avg$4,229Baseline
11:00 UTC Tue 14 Apr 26$1,58062.6% drop, alert FIRES
What’s interesting:
  1. The alert fires at 3,172(753,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 for incidents. (d) Check the payment-processor status pages (Stripe, PayPal). (e) Check BC Decline 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

CardWhy pair it with Revenue Drop Alert
Total RevenueThe full daily / weekly trend that this alert is the real-time guardian of.
BC Alert Channel Revenue DropPer-channel version. Catches drops concentrated in one channel that this store-wide alert masks.
BC Decline RateIf revenue dropped and decline rate spiked, the gateway is the cause.
BC Incomplete RateIf revenue dropped and incomplete rate spiked, the checkout iframe is the cause.
BC Failed Orders CountThe combined failure pulse, useful for the first-5-minutes diagnostic.
BC Alert Fulfilment DelayOften co-fires; an outage that breaks orders also delays whatever fulfilment was queued.
Order CountThe volume side. A revenue drop with stable order count means AOV moved (a discount went live unexpectedly).
BC Alert OOS SpikeA 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 shows the daily trend; today’s bar will be obviously short if the alert fired earlier in the day.
  2. Orders → All orders sorted by date descending shows the most recent orders; gaps in the timestamp sequence reveal when ordering stopped.
  3. BC Status for known platform issues.
  4. Settings → 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:
ReasonDirection
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):
CardExpected relationshipWhat causes legitimate divergence
stripe.stripe_total_revenueStripe-side hourly revenue should drop in lockstep if Stripe is the BC processorStripe 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_trendGA4 hourly revenue should drop in lockstep, modulo tracking gapGA4 misses 10-25% of orders; the GA4 number is noisier than this card.
paypal.pp_total_volumePayPal-side hourly should drop in lockstep if PayPal is the affected gatewayPayPal-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.

​
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 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 400ordermovesthehourlytotalby20400 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 or book a demo to see this metric running on your own data.