Skip to main content
Metrics type: Key Metrics • Category: Marketplace

​
At a glance

Real-time alert that fires when one or more OnBuy listings transition into status = suspended within the last 24 hours. The early-warning version of the standing onbuy_suspended_listings count, intended to surface clusters before they accumulate.

​
Calculation

Calculated automatically from your OnBuy 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 small UK toys-and-games seller, 27 Apr 26 09:00 BST. The alert fires showing 7 new suspensions in the last 24 hours. The drilldown groups by reason:
What it means for this seller. This is a textbook policy-change burst, not 7 independent issues. Five LEGO listings suspended simultaneously with price_policing as the reason almost certainly means LEGO updated their MAP schedule with OnBuy. Fixing each listing individually (raising prices to MAP) is correct, but the more important step is contacting OnBuy seller support to confirm the policy effective date so they do not auto-suspend the other LEGO listings the seller plans to upload next week. The 2 unrelated suspensions (board game, train set) are routine ops issues, both fixable inside an hour. The hero pattern to act on is the LEGO MAP change. The cost calculation:
The alert paid for itself the moment it fired; without it the seller might have noticed a £1,150 / month revenue drop in a fortnight when they could have caught it the same morning.

​
Sibling cards merchants should reference together

​
Reconciling against the vendor’s own dashboard

Where to look in OnBuy’s own dashboard: OnBuy does not natively send a per-burst notification, this is the gap our card fills. Their Seller Console sends individual emails per suspension (which get lost in inboxes when 5+ arrive together) but no aggregated 24-hour view.
OnBuy Seller Console (https://seller.onbuy.com) -> Notifications -> Filter: type = listing_suspended, time = last 24h
This Notifications view shows the same set of events but as a flat list, not grouped by reason. Why our number may legitimately differ: Internal identity: onbuy_alert_suspension <= onbuy_suspended_listings (since burst is delta over 24h, total is standing count) Burst should never exceed standing count; if it does, raise a sync issue.

​
Known limitations / merchant FAQs

The alert fired but I see only 1 listing suspended in OnBuy. Why? Sync timing. The API status flag for the other listings will appear within 5 to 15 minutes; refresh the Console after 15 minutes and they should all be visible. Alternatively, check Notifications -> Last 24h, which fires off the email queue (5 minutes faster than the status field). Why is my Suspension Burst higher than my new-suspended-today count? The card is rolling 24-hour, not calendar-day. If you check at 09:00 today, “24h” reaches 09:00 yesterday; “today” only reaches 00:00 today. Listings suspended yesterday afternoon count in the burst but not in today’s count. My burst showed 12 listings overnight. Should I panic? Not yet, but act fast. Open the drilldown and group by suspension_reason. If 8 to 12 share the same reason and the same brand, it is policy-driven (LEGO MAP, Apple authorisation, etc.) and resolution requires contacting OnBuy seller support, not fixing each listing. If reasons are scattered, it is most likely a data issue on your side: a supplier feed pushed bad attribute data. Does this card consider listings reinstated within the 24h window? Yes, the burst counts listings that transitioned to suspended within the window, even if they have since been reinstated. This is intentional: you want to know that flapping happened, not just whether listings are currently down. If you only want currently-suspended listings, use onbuy_suspended_listings. Why does the burst count differ between the dashboard and the email digest? The email digest is a daily snapshot at 09:00 BST; the dashboard is a live 24-hour rolling window. They will agree at 09:00 and diverge during the day. Action playbook on burst alert:
  1. Open the drilldown and group by reason. If clustered (>50% same reason), it is a policy event; jump to step 4. If scattered, treat as ops issues and continue.
  2. Sort by velocity x ASP. Use onbuy_revenue_at_risk as the proxy. Highest-impact first.
  3. Fix per-listing. Image issues: re-shoot; attribute issues: bulk-edit; uncategorised: assign category_id.
  4. For policy events (clustered). Open a single ticket with OnBuy seller support, include the cluster reason, all affected listing IDs, and ask whether they will release the policy or whether you need to comply (raise prices to MAP, etc.). Do not fix listings individually until the policy is confirmed; you may be reinstating something OnBuy will re-suspend within hours.
  5. Document in your ops log. Brand-MAP changes recur quarterly; keeping a log of which brands changed when saves you investigation time on the next burst.
Is this card worth using if I only have 50 listings? Yes, more so than for large catalogues. For a 50-listing seller, 5 suspensions is 10% of the catalogue and will materially move revenue; for a 5,000-listing seller it is 0.1% and barely moves the needle. Small catalogues need this alert most. Does the burst include listings I manually deactivated? No. We separate suspended (algorithmic / policy-driven) from deactivated (seller-initiated). Deactivated listings count under onbuy_inactive_listings, not here.

​
Tracked live in Vortex IQ Nerve Centre

Listings Suspension Burst (24h) is one of hundreds of KPI pulses Vortex IQ tracks across OnBuy 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 or book a demo to see this metric running on your own data.