Skip to main content
Metrics type: Key MetricsCategory: 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.

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,200oftotalinctax.OnTuesday14Apr26,thelivehourshows4,200 of `total_inc_tax`. On Tuesday 14 Apr 26, the live hour shows 1,580. 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

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: Cross-connector reconciliation (when payment processors and analytics are connected): 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.