Trips when last-24h revenue lags the prior-7-day baseline by >25%. The canary for a broken checkout / app / pixel.
At a glance
A rolling-window detector that compares the last 24h of SUM(totalPrice) against a 7-day baseline average and trips when the deficit exceeds 25%. The single most-watched alert in Vortex IQ, the canary for a broken checkout, a misfiring app, a pixel outage, or a payment-gateway issue.
| What it counts | SUM(totalPrice) for last 24h vs AVG(SUM(totalPrice) per 24h over prior 7 days). Trips when (last_24h ÷ prior_7D_avg) < 0.75, i.e. revenue is at less than 75% of expected. |
| VAT / tax treatment | Inherited from totalPrice. Same as Total Revenue, VAT-inclusive on UK / EU stores (taxesIncluded = true), VAT-exclusive on US stores. The alert ratio is currency-agnostic so this doesn’t affect the trigger, only the £ value displayed alongside. |
| Shipping | Included (part of totalPrice). |
| Discounts | Already deducted (totalPrice is post-discount). A heavy-discount day after a flat baseline can artificially trip the alert, see “false positives” in FAQ. |
| Refunds | NOT deducted. Refunds happening today are credits against orders placed earlier; the order’s totalPrice stays and so does its contribution to the 24h sum. |
| Cancelled / voided orders | Included if Shopify indexed them with a non-zero totalPrice. Voids that happen DURING the 24h window do reduce the count of orders but the £ contribution is usually small. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. For stores transacting in multiple currencies, the alert’s denominator (7D average) suffers the same currency mix as the numerator (last 24h), so the ratio is approximately stable. The £ value displayed is still the unconverted sum. |
| Channels / sources | All channels contribute. Online Store, POS, Buy Button, B2B, marketplaces. Day-of-week effects (POS-heavy retail spikes on Saturday) are flattened by the 7D rolling baseline because the baseline always includes the same day-of-week. |
| Time window | RT, recomputed every 15 minutes against a rolling 24h vs 7D baseline |
| Alert trigger | rolling 24h drop >25% vs prior 7D avg. Configurable per workspace. |
| Roles | owner, finance, marketing |
Calculation
Calculated automatically from your Shopify 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 Shopify Plus, average daily revenue around $14k. The alert fired at 14:23 EST on 09 Apr 26 (a Friday).| Window | £ revenue | Note |
|---|---|---|
| Prior 7-day average (02 Apr - 08 Apr) | $14,200 / day | Healthy baseline, normal week |
| Last 24h (08 Apr 14:23 - 09 Apr 14:23) | $4,860 | The trigger window |
| Ratio | 34.2% of baseline | Drop of 65.8%, far above the 25% trigger |
- Checked the storefront, the homepage loaded fine. Not an outage.
- Checked checkout, navigated to a PDP, added to cart, hit checkout. Got an error: “Unable to process payment, please try again later.” Stripe-side error.
- Checked Stripe Dashboard, no API errors. But noticed Apple Pay and Google Pay were both failing.
- Checked Shopify Status, no platform-wide incident.
- Checked the brand’s Shopify app installs, identified that a one-click upsell app had pushed an update at 04:00 EST that conflicted with the new Shop Pay Installments flow. Customers landing in the upsell modal couldn’t complete checkout via Apple/Google Pay.
- Disabled the offending app, revenue resumed within 12 minutes.
- The 25% threshold caught it but the 65% ratio confirmed it was real. A single bad hour might dip below 25% briefly (e.g. an ad campaign paused at midnight), but a 24h rolling window at 34% of baseline is unambiguous.
- The 7D baseline absorbed day-of-week effects. Friday revenue is different from Monday revenue for this brand; the 7D window includes the prior Friday so the baseline is calendar-aware.
- The cause was not Shopify-side. The status page was clean. Almost all “checkout broken” alerts have an app-conflict or Shopify-third-party-payment-routing root cause, not Shopify itself. This is structurally true.
- The £ value matters as much as the percentage. A 65% drop on a 130 issue and probably a single absent ad campaign. The same percentage drop on a $14k/day store is a five-figure ops emergency. Always read the ratio AND the absolute £ deficit together.
- Speed of detection is the value. Without the alert, the merchant would have noticed at 18:00 when the daily report arrived, missing 4+ more hours of revenue. The alert turned a 14h outage into a 10h outage, $5,600 saved.
- The recovery edge. Once the alert clears (last 24h returns to >75% of baseline), Vortex IQ Mind logs a clear event so the team knows the issue is resolved. The card itself stays orange / red until the rolling 24h fully recovers, often 4 to 12 hours after the fix.
Sibling cards merchants should reference together
Revenue Drop Alert is the smoke detector. These cards are the diagnostic toolkit:| Card | Why pair it with Revenue Drop Alert |
|---|---|
| Total Revenue | The 30D context. Tells you whether this dip is anomalous or part of a longer slide. A short-term alert against a long-term decline calls for a different action than a short-term alert against a stable trend. |
| Order Count | If revenue is down but order count is flat, basket size collapsed (possible discount-day weirdness). If both are down, demand or checkout broke. |
| Conversion Rate | The diagnostic. A revenue drop with stable traffic + stable orders = checkout broken. A revenue drop with traffic drop = ad-spend issue or pixel issue. |
| Active Ads on Out-of-Stock SKUs | If revenue dropped because a top-velocity SKU went OOS during the window, this card surfaces it instantly. |
| Stripe Total Revenue | If Shopify revenue dropped but Stripe didn’t, the gap is non-Stripe payment methods. If both dropped together, the dip is real and processor-agnostic. |
| GA4 Revenue Trend | Cross-check. If GA4 also shows the drop, it’s likely real demand. If GA4 shows healthy traffic but Shopify shows revenue collapse, checkout is broken. |
| Datadog Incidents | If a Datadog incident is open against your storefront / payment / app stack at the time of the drop, that’s almost certainly the cause. |
| Revenue at Risk (live incident) | The composite £/min-loss view that pairs this alert with active monitoring incidents. |
Reconciling against the vendor’s own dashboard
Where to look in Shopify Admin: Shopify doesn’t have a native equivalent to this alert. The closest views are:- Home → Total sales today, the headline today-vs-yesterday tile, manually compared to the prior 7 days.
- Reports → Sales over time, set the range to Last 30 days and visually inspect the tail. The alert’s drop should be visible as a sharp dip on the right edge of the chart.
- Live View. Shopify’s real-time map. Useful for confirming the drop is happening NOW vs already recovering.
- Shopify Insights notifications: Shopify itself sends “Your sales are down” emails on a much slower cadence (daily) and with looser thresholds. Useful as a backup but not a real-time canary.
- Apps like Triple Whale / Lifetimely sales-drop alerts: similar idea, different baseline calculations. Will fire at slightly different times and different thresholds. Treat as an independent confirmation not a duplicate.
| Reason | Direction | Why |
|---|---|---|
| Sync lag | Ours lower for live windows | Vortex IQ ingests via Shopify webhooks; the most recent 5 to 15 minutes of orders may not be in yet. The alert’s denominator is robust to this (7D average) but the numerator (last 24h) can read low transiently. The detector waits for a 30-minute confirmation window before firing to mitigate. |
| Time zone | Boundary shifts | Shopify Admin runs in shop time zone; the alert runs on UTC rolling 24h. The 7D baseline normalises this so day-of-week effects don’t trip the alert, but the absolute £ deficit you see in the alert vs in Admin can differ slightly. |
| Multi-currency | Approximately stable ratio | The arithmetic sum across currencies isn’t FX-converted, but since the same currency mix appears in both numerator and denominator, the ratio is approximately stable. The £ deficit shown is the unconverted sum. |
| Test orders | Ours slightly higher | Vortex IQ doesn’t yet filter Order.test. A flood of test orders during a QA session could mask a real drop or create a false negative. Rare in practice. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_total_revenue | Should drop in lockstep if Stripe is the primary processor | If Stripe is healthy but Shopify is dropping, the issue is non-Stripe payment methods (PayPal, Shop Pay Installments, gift cards) or pre-Stripe checkout failure. |
google_analytics.ga_revenue_trend | Should drop in lockstep if pixel is firing | If GA4 doesn’t show the drop, the pixel is broken (which itself can CAUSE a revenue drop downstream by breaking attribution). |
datadog.dd_incident_count | Open incident at time of drop = strong cause signal | An incident on storefront / payment / checkout app at the alert window is the smoking gun. |
newrelic.nr_incident_count | Same as Datadog, different vendor | Same caveat. |
Known limitations / merchant FAQs
Why did this alert fire when my revenue is fine? Three common false-positive causes:- A discount day pulled forward demand. If the prior 7 days included a “20% off” Black Friday-style burst, the baseline is artificially high, today’s normal trading reads as a “drop”. Disable the alert for 7 days after large promotions, or use a workspace setting to bump the threshold to 35% during sale-tail periods.
- A timezone artefact. Stores that bill in shop-time but the alert runs in UTC can see a phantom drop near a daylight-savings boundary. Rare, but happened to UK stores on 30 Mar 26.
- Sync lag during a write spike. A flash sale ingesting 2,000 orders in 10 minutes can briefly delay the OpenSearch index, making the last 24h look low until the index catches up. The alert has a 30-minute confirmation window to mitigate but it’s not bulletproof.
sourceName reliably. Per-channel revenue drop alerts are on the roadmap. Manual workaround: set up a Shopify Flow trigger on order_created filtered by sales channel and pipe it to a webhook in Vortex IQ.
The alert says “drop > 25%” but my revenue is 73% of baseline. Why isn’t it firing?
Because the alert needs a sustained drop. The 24h numerator and the 7D denominator are both rolling. The detector requires the ratio to stay below 0.75 for at least 30 minutes before firing, to avoid noise from individual large refund hits or brief sync gaps. If you saw 73% momentarily, that’s the 30-min confirmation window working as designed.
My business has high day-of-week variance (B2B closes Fri-Sun). Is this alert reliable?
Yes, because the 7D baseline is calendar-aware. Tuesday revenue is compared against the average of the prior 7 days which always includes the prior Tuesday. So Friday-vs-Friday, Saturday-vs-Saturday, etc. The exception is irregular calendars (lunar new year, Eid, religious / cultural holidays). Around those, expect false positives or false negatives. Pause the alert during known irregular weeks.
Why is the £ deficit shown different from my Stripe Dashboard’s daily revenue?
The card’s £ deficit is computed against the 7D baseline. Stripe Dashboard shows raw daily volume, no baseline comparison. They’re answering different questions. To reconcile: the card’s “last 24h” raw figure should match Stripe’s last 24h within the gap explained in Total Revenue reconciliation, Stripe captures only Stripe-routed payments.
Can the alert fire from refunds alone?
Indirectly yes, but rarely. Refunds don’t reduce the totalPrice of the original orders that count in the 24h window. But refunds DO appear as negative entries in some orders’ totalRefundedSet, and a major refund event (like a recall) can correlate with a real revenue drop because customers stop ordering. The alert is fundamentally a sales-side detector, not a refund detector. Use Refund Rate for the refund-side view.
Action playbook when this alert fires:
- Check Shopify Status (status.shopify.com). If platform-wide, wait it out and notify customer-service.
- Manually attempt a test purchase end-to-end. Add to cart, hit checkout, complete with each payment method (card, Apple Pay, Google Pay, PayPal). Note any error messages.
- Check Datadog Incidents and NewRelic Incidents. An open incident on storefront / checkout / payment is the prime suspect.
- Check recent Shopify app updates (Settings → Apps → Activity). A 4am app push is a common cause.
- Check Stripe Total Revenue. If Stripe is healthy but Shopify isn’t, the issue is non-Stripe checkout (PayPal, Shop Pay Installments, gift cards).
- If pixel-related, check GA4 Revenue Trend, if GA4 still shows healthy traffic + checkout starts, but no purchases, the GTM / pixel layer broke.
- Document the cause in the incident timeline. Vortex IQ Mind’s auto-generated investigation report will be your starting point; flesh it out with the manual checks above.