> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # INR Cases Burst (24h), eBay > INR Cases Burst (24h) for eBay stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Marketplace](/nerve-centre/connectors#connectors-by-type) ## 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](/nerve-centre/kpi-cards/ebay/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** | Five things to notice: 1. **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.** 2. **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). 3. **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. 4. **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. 5. **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](/nerve-centre/kpi-cards/ebay/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](/nerve-centre/kpi-cards/ebay/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](/nerve-centre/kpi-cards/ebay/defect-rate) | Where unresolved bursts ultimately land. Each auto-resolved INR adds to the defect total. | | [Cases without Resolution](/nerve-centre/kpi-cards/ebay/cases-closed-w-o-resolution) | The downstream graveyard. Bursts that aren't responded to fast become rows here. | | [Revenue at Risk](/nerve-centre/kpi-cards/ebay/revenue-at-risk) | The £-view of the same case population. Use it for cash-flow prioritisation when triaging the burst. | | [Health Score](/nerve-centre/kpi-cards/ebay/ebay-health-score) | Composite that captures the operational degradation a sustained burst will cause. | | [Shopify Total Revenue](/nerve-centre/kpi-cards/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](/nerve-centre/amazon/atoz_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](https://www.ebay.com/sh/ord/cases), filter by **Date opened: Last 24 hours**. > [Performance → Service Metrics](https://www.ebay.com/sh/performance/servicemetrics) 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. | **Why our number may legitimately differ from a manual count in Seller Hub:** | 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. | **Cross-connector reconciliation against other connectors the same seller may run:** | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | [`amazon.atoz_claims`](/nerve-centre/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`](/nerve-centre/kpi-cards/shopify/refunded-orders) | 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. | ***
Same-shape marketplace peer (for sellers running multiple marketplaces) The same dispute-burst-detection pattern can be applied on Amazon. This is **not a reconciliation**, the underlying case systems are independent. The cross-link helps multi-marketplace sellers run shared incident-response playbooks. * [`amazon.atoz_claims`](/nerve-centre/amazon/atoz_claims), Amazon's A-to-z claim equivalent.
## 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](/nerve-centre/kpi-cards/ebay/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. *** ### Tracked live in Vortex IQ Nerve Centre *INR Cases Burst (24h)* is one of hundreds of KPI pulses Vortex IQ tracks across eBay 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.