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).
| What it counts | COUNT(INR cases WHERE case_opened_at >= now() - 24h). Count of NEW INR cases opened in the trailing 24-hour window, regardless of resolution status. |
| Listing-format scope | All formats. Bursts can come from any format but are typically driven by fixed-price, since that’s where most volume sits. |
| GMV / fees framing | Not applicable, this is a count alert. The £-exposure of the burst is captured in Revenue at Risk. |
| Promoted Listings | Promoted-driven orders generate INR cases at similar rates; bursts can include both organic and promoted contributors. The card shows per-source breakdown when expanded. |
| Multi-site aggregation | Counts new INR cases across every connected marketplaceId. A burst on one site can trip the alert; the card surfaces the originating site to direct investigation. |
| Currency | Not applicable, count metric. |
| Best-Offer-resolved orders | Counted identically to BIN orders in the burst signal. |
| Refunds | A seller-issued refund closing a case favourably does NOT remove that case from the burst count, the goal is detecting the opening of cases, not their resolution. |
| Cancellations | Pre-payment cancellations are not eligible for INR. |
| Time window | 24H (rolling, not calendar-day). The window slides forward continuously; the alert can fire at any time of day. |
| Alert trigger | >2 new INR cases opened in the trailing 24h. Threshold tunable per-workspace (high-volume sellers can tune up to 5; low-volume to >0). |
| Roles | owner, operations |
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.| Case opened | Buyer location | Order placed | Carrier | Tracking last scan | Order value |
|---|---|---|---|---|---|
| 24 Apr 26 04:18 PT | Texas | 14 Apr 26 | USPS | 16 Apr 26 “In transit, Memphis TN” | $86 |
| 24 Apr 26 06:31 PT | Florida | 13 Apr 26 | USPS | 16 Apr 26 “In transit, Memphis TN” | $124 |
| 24 Apr 26 09:48 PT | Georgia | 14 Apr 26 | USPS | 16 Apr 26 “In transit, Memphis TN” | $58 |
| 24 Apr 26 11:42 PT | North Carolina | 13 Apr 26 | USPS | 16 Apr 26 “In transit, Memphis TN” | $92 |
| Burst total | 4 cases, $360 at risk |
- 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
| Card | Why pair it with INR Burst Alert |
|---|---|
| Open INR Cases | The full list with SLA clocks. Use this for case-by-case action; the burst alert tells you to open this card. |
| Late Shipment Rate | Often the leading indicator of an INR burst. Carrier handover delays show in late-shipment metrics 24 to 48 hours before INRs land. |
| Defect Rate | Where unresolved bursts ultimately land. Each auto-resolved INR adds to the defect total. |
| Cases without Resolution | The downstream graveyard. Bursts that aren’t responded to fast become rows here. |
| Revenue at Risk | The £-view of the same case population. Use it for cash-flow prioritisation when triaging the burst. |
| Health Score | Composite that captures the operational degradation a sustained burst will cause. |
| Shopify Total Revenue | If the burst is carrier-driven, sister stores on Shopify shipping the same SKUs via the same carrier may see a parallel chargeback / refund pattern. |
| Amazon A-to-z Claims | Marketplace peer; cross-platform burst signal. A simultaneous Amazon A-to-z burst confirms a carrier-side problem rather than an eBay-specific issue. |
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:
| Topic | Detail |
|---|---|
| Timezone | Burst window is UTC-anchored rolling 24h, regardless of seller account timezone. A seller in Pacific Time and a seller in BST share the same global window definition. |
| Settlement / payout impact | None directly. Each individual INR within the burst can affect funds-on-hold and payouts; the alert itself is informational. |
| Promoted Listings cost reporting lag | None. |
| API throttling | Webhook-driven; new cases push within 30 to 90 seconds. Daily polling fallback runs every 5 minutes. The alert can fire within 90 seconds of the threshold being crossed. |
| Alert latency | Once the threshold is crossed, the Vortex IQ Nerve Centre dispatches the alert via configured channels (email, Slack, Teams, mobile push) within 60 seconds. |
| Reason | Direction | Why |
|---|---|---|
| Window definition | Either | Vortex IQ uses a continuous rolling 24h; Seller Hub’s date filter typically operates on calendar-day boundaries. A case opened at 23:00 yesterday is in the rolling window but not the calendar-day window. |
| Refresh latency | Ours within 90s | A case opened minutes ago may be in Seller Hub before the webhook fires. Sub-2-minute discrepancies are normal. |
| Resolution-state filter | Same on both | The burst counts new cases regardless of whether they were resolved within the 24h. Seller Hub matches if the date filter is set correctly. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
amazon.atoz_claims | Marketplace peer. A simultaneous burst on Amazon’s A-to-z claims confirms a carrier-level or warehouse-level problem affecting both channels. | Independent populations; useful for diagnosis, not 1-to-1 reconciliation. |
shopify.refund_count | If shipping the same SKUs via the same carrier from a Shopify storefront, expect a parallel refund spike. | Independent populations. Use as confirmation of a carrier-driven root cause. |
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.