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.
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).- 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: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.
Cross-connector reconciliation:
The alert is composite-signal-aware. When fired, Vortex IQ Mind cross-checks these connectors automatically:
The Vortex IQ Mind investigation report (auto-generated when this alert fires) reads each of the above, plus checks Shopify Status, top-product OOS state, and recent app installs / updates, and ranks the most likely cause.
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.