From February 28, 2026, an On-Time Delivery Rate (OTDR) below 90% on seller-fulfilled orders triggers deactivation at the listing level, deactivating the worst-contributing ASINs rather than the whole catalogue. This narrows the blast radius of a bad month considerably. It also makes the metric harder to ignore, because a handful of problem products can now be removed while everything else keeps selling.
What is OTDR and how is it calculated in principle?
OTDR measures the share of seller-fulfilled orders delivered by the promised delivery date. It applies to orders you ship yourself, not to Fulfilment by Amazon (FBA) orders, where Amazon controls the fulfilment and therefore owns the outcome.
The calculation depends on two things Amazon has to be able to see. The first is the delivery promise shown to the buyer, which Amazon derives from your handling time and the transit time associated with the shipping option chosen. The second is evidence of when delivery actually happened, which normally comes from carrier tracking events passed back to Amazon.
That second dependency is the one sellers underestimate. If Amazon cannot see a delivery event, it cannot credit an on-time delivery, and an order that arrived perfectly on time can still count against you.
Important note: OTDR is a shipping-data metric before it is a logistics metric. Many failures are parcels whose tracking never told Amazon they arrived.
What exactly changed on February 28, 2026?
The consequence changed, not the threshold. As of February 28, 2026, falling below 90% OTDR on seller-fulfilled orders results in deactivation at the listing level, with Amazon deactivating the ASINs contributing most to the shortfall, rather than deactivating the seller's whole catalogue. This is confirmed via an Amazon Seller Central forum thread and corroborated by multiple seller-services sources.
The mechanism is worth stating plainly: Amazon identifies which of your ASINs are dragging the metric down and removes those, leaving the rest of your listings live.
What has not changed
- The 90% level remains the trigger point associated with this change.
- OTDR remains a seller-fulfilled metric. FBA orders are not the subject of this rule.
- The underlying dependency on carrier tracking data reaching Amazon is unchanged.
Why is listing-level deactivation materially different from catalogue-level?
Catalogue-level deactivation is a business-ending event. Listing-level deactivation is an operational problem.
Under blanket deactivation, one badly performing product line could take down every ASIN you sell, including profitable, well-run lines with no delivery issues. Under listing-level deactivation, the damage is contained to the products actually causing it.
That containment cuts both ways.
- The downside is smaller. A single problematic SKU no longer threatens the whole account's selling ability.
- The likelihood of some enforcement is arguably higher. A narrower, more surgical action is easier for a platform to apply than a catastrophic one, so sellers should not assume the rule will be used sparingly.
- The pain lands on your best products. The ASINs contributing most to a shortfall are often your highest-volume ones, simply because they generate the most orders.
- Diagnosis becomes essential. Under a blanket rule the answer was "fix everything". Under a listing-level rule you need to know which ASINs are failing and why, which requires order-level shipping data rather than a dashboard percentage.
A worked implication: if one ASIN ships from a slower third-party supplier while the rest of your catalogue ships from your own warehouse, that ASIN is now individually exposed. Previously it endangered everything; now it endangers itself, but it will be found.
How does Buy Shipping and Veeqo protection work?
Amazon Buy Shipping and Veeqo produce OTDR-protected labels, and using them, together with shipping settings automation, confers protection on the resulting orders. This is the most direct lever available to a seller-fulfilled merchant.
The logic is straightforward from Amazon's side. When you buy the label through Amazon's own tooling, Amazon knows which service was purchased, what transit time it implies and which carrier events correspond to it, so it can assess the delivery promise against data it trusts. When you buy the label elsewhere and upload tracking afterwards, Amazon is relying on data you supply and on carrier events it may or may not be able to interpret cleanly.
Practical steps
- Move eligible volume onto Buy Shipping or Veeqo labels. This is the single change with the clearest effect on OTDR exposure.
- Turn on shipping settings automation. Protection applies to the combination of protected labels plus automated shipping settings, not to labels alone.
- Identify what cannot move. Some volume cannot go through Buy Shipping, for example certain international lanes or specialist carriers. Treat it as uncovered exposure and manage it separately.
- Check coverage rather than assume it. The proportion of seller-fulfilled orders carrying protected labels tells you how much of the metric you actually control.
What should you do about tracking and scan data quality?
Fix the data before you fix the logistics, because a large share of OTDR damage is data failure rather than delivery failure. Three patterns account for most of it.
Late or missing upload. Tracking that reaches Amazon after the fact, or not at all, cannot support an on-time determination.
Wrong or malformed tracking numbers. A number that does not resolve on the stated carrier's network is worse than useless, because it looks like compliance while providing no evidence. Carrier mismatch does the same damage: selecting the wrong carrier when uploading means Amazon queries the wrong network, which is common with consolidators and regional final-mile partners operating under a different brand to the one printed on the label.
Events that stop before delivery. Some carriers, particularly on international and multi-leg routes, produce a clean origin scan and then go quiet. The parcel arrives; the evidence does not.
The remedy is monitoring rather than reporting. You want to know, while there is still time to act, which orders have no movement, which have stalled mid-route and which have a delivery event that never propagated. A tracking layer that normalises events across carriers, such as Ship24, makes those exceptions visible in one place.
A short diagnostic checklist
- What percentage of seller-fulfilled orders carry a Buy Shipping or Veeqo label?
- How long, on average, between despatch and tracking upload?
- Which carriers in your mix produce the highest rate of orders with no delivery event?
- Which specific ASINs sit below 90% OTDR, and do they share a carrier, an origin or a supplier?
What about the reported 93.5% threshold and weekly reviews?
Do not plan around it. A reported change to a 93.5% threshold from June 29, 2026, with weekly rather than monthly review, could not be verified on any Amazon-owned page as of August 2026. It may conflate a separate programme requirement with the general OTDR policy, and no confirmed Amazon documentation supports it.
Two related figures deserve the same caution. Amazon Valid Tracking Rate thresholds of 95% and 99% both circulate widely in seller communities. As of August 2026, neither is confirmed.
How to handle unconfirmed thresholds sensibly: build to the confirmed requirement, but build headroom. Operating comfortably above 90% protects you whether or not a tighter threshold ever materialises. What you should not do is announce internal policy changes, renegotiate carrier contracts or restructure handling times on the basis of a figure no one can source to Amazon.
Is this change good news for sellers?
On balance, yes, but it rewards sellers who measure at the order level and punishes those who watch a single dashboard number. Listing-level deactivation removes the worst outcome from the table: no seller should now lose an entire catalogue because one product line has a delivery problem.
The trade is that vagueness no longer works. A catalogue-wide metric could be managed with catalogue-wide effort, but a rule targeting specific ASINs demands that you know which ASINs are at risk and why, and that knowledge lives in per-order shipping and tracking data.
The most sensible reading, as of August 2026, is that Amazon is making enforcement more proportionate and therefore more usable. The seller response should be equally proportionate: move as much volume as possible onto protected labels, keep tracking uploads fast and accurate, watch coverage rather than just the headline percentage, and ignore thresholds that cannot be sourced to Amazon itself.
