At a glance
Real-time alert that fires when one or more OnBuy listings transition intostatus = suspendedwithin the last 24 hours. The early-warning version of the standingonbuy_suspended_listingscount, intended to surface clusters before they accumulate.
| What it counts | COUNT(listings WHERE status changed to 'suspended' WITHIN last_24h). Deduplicated per listing (a listing flapping suspended -> reinstated -> suspended counts once). |
| API endpoint | Derived. Diff of consecutive GET /v2/listings?status=suspended polls every 15 minutes. New entries to the suspended set are tagged with the timestamp of first appearance. |
| Currency | n/a (count). |
| Tax / fees | n/a. |
| Refunds | n/a. |
| Cancellations | n/a. |
| Channel scope | OnBuy only. |
| Time window | 24H (rolling 24-hour window). |
| Alert trigger | >0. Any new suspension is actionable. The drilldown groups by suspension_reason. |
| Sentiment key | missing_attrs. |
| Burst signal | 5+ suspensions in the same 24h window with the same reason indicates a category-wide policy change, not random ops issues. Engage OnBuy seller support before fixing one-by-one. |
| Roles | owner, operations, marketing. |
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:| Reason | Count | Listings affected |
|---|---|---|
| price_policing (LEGO MAP) | 5 | LEGO sets 41391, 60345, 31133, 75345, 21326 |
| image_quality | 1 | board-game-azul-classic |
| missing_attribute (age_group) | 1 | toy-train-wooden-set |
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:
Sibling cards merchants should reference together
| Card | Why it matters next to Suspension Burst | What the combination tells you |
|---|---|---|
| Suspended Listings | The standing total. | Burst tells you “today”; standing total tells you “still unresolved”. |
| Revenue at Risk | The £ exposure. | A single high-velocity listing in the burst can outweigh five low-velocity ones. |
| Catalogue Drift vs Amazon UK | Diagnoses price_policing bursts. | If burst correlates with drift, Amazon UK price changes triggered the OnBuy MAP enforcement. |
| OnBuy vs DTC Price Gap | Diagnoses MAP-style bursts. | If your DTC price is below OnBuy’s, brand owners may have flagged you. |
| Listing Quality Score | Leading indicator. | Listings <60 quality score are 4x more likely to feature in a burst within 90 days. |
| Total Revenue | Downstream impact. | Bursts >5 typically translate to a 5 to 10% revenue dip within 7 days unless fixed same-day. |
| Auth Token Health | False-positive guardrail. | If token failed, the diff calculation may show an artificial burst when the next sync recovers. |
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:
| Reason | Direction | Why |
|---|---|---|
| Sync window | Slight | We poll every 15 minutes; OnBuy notifications can arrive minutes earlier or later. |
| Email vs API status | Email faster | Suspension emails fire as the algorithm runs; the API status flag updates ~5 minutes later. |
| Reinstated within 24h | Different | A listing suspended at 09:00 and reinstated at 14:00 still shows in our 24h burst; the Notifications view filters them out. |
| Bulk operations | Same | Mass suspensions (50+) sometimes process in batches; our burst card may show 50 across two adjacent 15-minute windows. |
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 bysuspension_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:
- 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.
- Sort by velocity x ASP. Use
onbuy_revenue_at_riskas the proxy. Highest-impact first. - Fix per-listing. Image issues: re-shoot; attribute issues: bulk-edit; uncategorised: assign category_id.
- 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.
- 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.
suspended (algorithmic / policy-driven) from deactivated (seller-initiated). Deactivated listings count under onbuy_inactive_listings, not here.