At a glance
A real-time alert that fires when more than 2 new INR cases land within a rolling 24-hour window. The signal you want for the difference between “scattered buyer behaviour” (1 to 2 cases per day, normal noise) and “systemic incident” (3+ in 24h, almost always a carrier delay, warehouse mis-routing, or label-print failure).
Calculation
Calculated automatically from your eBay 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 fashion seller running ebay.com only. Date: 24 Apr 26, alert fires at 11:42 PT.
Five things to notice:
- The pattern is unmistakable. Four buyers in the southeast US, all USPS, all with the last tracking scan stuck at Memphis TN on 16 Apr. The Memphis distribution centre had a sortation incident; packages are queued, not lost. This is exactly what the alert is engineered to catch.
- The alert beats the buyer-by-buyer signal. Without this card, the seller might respond to each INR individually over 4 days, missing the carrier-level pattern entirely. With the alert, ops can identify the Memphis bottleneck within hours and respond systematically (proactive message to all affected buyers, file a USPS service-locator search, set expectation).
- Auto-resolution risk is substantial. All 4 orders shipped 8 to 10 days before INR was filed. The 8-day INR auto-resolution clock runs from case-open, so the seller has 8 days from each case-open timestamp to respond. The first-opened case (04:18 PT) auto-resolves at 04:18 PT on 02 May 26 if no response, that’s the cliff.
- The fix is process-led, not case-by-case. Best practice: paste the USPS tracking link with a prepared “We’ve identified a USPS Memphis distribution-centre issue affecting your delivery; we’re tracking it and will refund or replace if not delivered by [+5 days]” template, in every case at once. eBay accepts this as a good-faith seller response and pauses auto-resolution while the buyer awaits delivery.
- Recurring bursts mean a carrier-mix problem. If the same alert fires three weekends in a row with USPS-routed orders, the seller should consider switching carrier blends (e.g. UPS Ground for southeast US destinations). Bursts that recur are a systemic signal, not a coincidence.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in eBay Seller Hub: eBay does not publish a “burst” alert; this is a Vortex IQ-defined signal. To reconcile, manually count cases opened in the last 24 hours:Seller Hub → Orders → Cases, filter by Date opened: Last 24 hours. Performance → Service Metrics shows historical INR-rate trend, useful for confirming whether a burst is part of a longer-term degradation.Timing, settlement, and reporting-lag table:
Why our number may legitimately differ from a manual count in Seller Hub:
Cross-connector reconciliation against other connectors the same seller may run:
Known limitations / merchant FAQs
Why is the threshold set to >2 cases? Because 1 to 2 INR cases per day is the baseline noise for most established sellers, just scattered buyer behaviour. The third case in 24 hours is statistically unusual for sellers under £200k monthly GMV; it almost always points at a single root cause (carrier delay, warehouse mis-routing, label-print failure). The threshold is tunable per workspace; high-volume sellers (£500k+) should consider tuning to >5. What if my volume is so low that the threshold rarely trips? Tune it down to>0 for low-volume sellers (under 200 orders / month). At low volume, even a single case represents a signal worth investigating. The card YAML supports per-workspace threshold tuning.
The alert fired but the cases are unrelated, what now?
Sometimes a coincidence. If the cases span different carriers, different geographies, and different SKUs, it’s likely random clustering. Acknowledge the alert and proceed to case-by-case resolution via Open INR Cases. The alert is a signal to investigate, not a guarantee of a root cause.
How do I find the root cause when the alert fires?
Three quick filters on the case list: (1) Carrier: same carrier across all cases? Likely a carrier hub issue. (2) Geography: same destination region? Likely a regional facility issue. (3) SKU: same product? Likely a fulfilment or inventory issue. The Vortex Mind investigator can run this analysis automatically when invoked from the alert.
Does Best Offer affect the burst pattern?
Not meaningfully; Best-Offer-resolved orders generate INRs at similar rates to BIN. The ratio of Best-Offer-driven to BIN-driven cases in a burst is usually proportional to the seller’s overall Best-Offer share.
Promoted Listings: bursts can come from promoted SKUs?
Yes, equally. Promoted-driven orders ship and disputed identically to organic. If a promoted SKU is in a defect-prone category (clearance, refurbished), bursts may include disproportionately many promoted orders. Check the burst breakdown.
Multi-site bursts: same alert?
The card aggregates across marketplaceId, so a burst on UK + a burst on US can combine to trip the alert. The expanded view shows which site contributed which cases, useful for diagnosis (a UK-site-only burst is rarely a US-carrier issue).
Why doesn’t this match Shopify or Amazon?
Independent populations. A simultaneous burst on Shopify (refunds) or Amazon (A-to-z claims) confirms a carrier or warehouse issue affecting both channels. Use that signal as diagnosis confirmation, not as a reconciliation; the case systems themselves don’t share data.
Does today-side volatility matter?
Less than for revenue cards. Cases land throughout the day; if you’re watching the card live during a buyer-dispute spike, you’ll see the count tick up. The alert fires the moment the threshold is crossed and re-fires only if the count crosses an additional notch (e.g. >5 if the threshold is dynamic). Default behaviour: one alert per crossing per 24h window.
What’s the relationship between this and TRS status?
A sustained burst (3+ cases per day for 3+ days running) will materially move defect rate, which threatens TRS. The alert is the early-warning signal; respond to bursts within the 24h window to keep auto-resolutions to a minimum, and TRS is preserved.