At a glance
Share of EasyPost-routed parcels that hit a delivery exception in the period: a tracking status that signals the parcel is stuck, mis-routed, undeliverable, refused, damaged, or otherwise off the normal in-transit-to-delivered path. Because EasyPost rate-shops across many underlying carriers (USPS, FedEx, UPS, DHL, regional carriers such as OnTrac), this single dial aggregates the exception behaviour of every carrier your rules picked. It is the leading indicator for the despatch operation: a rising exception rate today predicts a falling on-time rate, a rising failed-delivery count and a rising claim volume over the next 24 to 72 hours.
Calculation
Calculated automatically from your EasyPost tracking data. The card divides parcels that hit an exception status by parcels with any tracking activity in the window:exception_rate = COUNT(trackers WHERE status IN (failure, error, return_to_sender) OR stale-unknown) / COUNT(trackers WHERE status != pre_transit) over the rolling 30 days.
Two grounding points that follow from the detail and time_window:
- EasyPost is the normalisation layer, not the source of truth for the scan. The underlying carrier produces the raw scan (for example USPS
21“delivery exception” or a FedEx delivery-exception code); EasyPost maps it to a normalised status andstatus_detail. The card reads EasyPost’s normalised status so a single threshold works across every carrier. To compare against a carrier’s own portal, compare our blended number against that carrier’s slice (see Reconciling below). - The
vsPcomparison drives interpretation. The dial value is the current 30-day rate; the period-over-period delta tells you whether it is moving. A steady 2.4 percent is unremarkable; 2.4 percent up from 1.6 percent last period is the signal, even though it has not crossed the 3 percent alert line yet.
Worked example
A US DTC supplements brand based in Austin, around 5,400 outbound parcels per week, all routed through EasyPost with a rate-shop rule that prefers USPS Ground Advantage for sub-1lb items, UPS Ground for heavier parcels, and FedEx Home Delivery as failover. Reading taken at 09:00 CT on 14 Apr 26 for the trailing 30 days (15 Mar 26 to 13 Apr 26), compared with the prior 30 days. Blended across carriers:
The dial reads 2.4 percent, up from 2.0 percent last period. The
>3% alert is not tripped at the blend, but it is moving the wrong way. Five things to notice:
- The blend hides the carrier that broke. FedEx Home Delivery jumped from 1.9 to 3.4 percent while everything else held. The blended dial only moved 0.4 points because FedEx is 10 percent of volume, but the FedEx slice nearly doubled. Open OTD by Underlying Carrier the moment this dial ticks up; the carrier breakdown is where the action is.
- International is structurally worse and that is normal. DHL eCommerce at 7.6 percent looks alarming next to USPS at 2.3 percent, but cross-border parcels carry customs holds, longer dwell and higher address-quality risk. Judge it against its own baseline (7.2 percent prior), not against the domestic carriers.
- The exception rate leads the failed-delivery count. Today’s 566 exceptions become tomorrow’s Failed Deliveries and next week’s Open Claims. At a typical 25 to 40 percent exception-to-failure conversion, expect roughly 140 to 230 of these to end as a non-delivery. Staff the customer-service queue now, not when the failures land.
- Read it next to the rate-shop decision. If FedEx is failing more, the rate-shop rule sending failover volume to FedEx is now buying cheaper labels that cost more in exceptions and claims. The Carrier-Mix Savings vs Single-Carrier Baseline saving is real, but net of exception cost it may be smaller than the headline suggests.
- A spike across all carriers at once is not a carrier problem. If every slice rises together, suspect an upstream cause: bad address data from a recent checkout change, a weather event, or a national holiday backlog. A spike isolated to one carrier points at that carrier’s network. The shape of the breakdown tells you which.
Sibling cards merchants should reference together
Exception rate is the leading indicator. Pair it with these to diagnose and quantify the downstream impact:Reconciling against the source
Where to look in EasyPost’s own tooling: EasyPost is a multi-carrier aggregator, so there are two layers to reconcile against. First, the EasyPost dashboard under Logs → Trackers lists every Tracker with its current normalised status andstatus_detail; filter by status failure, error and return_to_sender over the same 30-day window to count exceptions. The Tracking API (GET /v2/trackers?status=failure) returns the same population programmatically. Second, the underlying carrier’s own portal holds the authoritative scan: the USPS Business Customer Gateway, the FedEx tracking and reporting tools, the UPS dashboard, and so on. EasyPost is the normalisation layer over those scans; the carrier portal is the source of the scan itself.
The closest like-for-like EasyPost view is Trackers, Last 30 Days, status in (failure, error, return_to_sender), outbound only.
Why our number may legitimately differ from EasyPost’s dashboard or the carrier portal:
Known limitations / merchant FAQs
Why is one blended number useful if my carriers behave so differently? The blend is the right number for “is my despatch operation healthy overall” and for setting a single alert that does not need per-carrier tuning. The moment it moves, you drop into OTD by Underlying Carrier and Shipments by Underlying Carrier to find the carrier driving it. Think of the blend as the smoke alarm and the breakdown as the location of the fire. My international exception rate is always high. Is that a problem? Not on its own. Cross-border parcels carry customs holds, longer dwell, and higher address-quality risk, so 5 to 10 percent is common where domestic sits at 1 to 3 percent. Judge international against its own historical baseline. If it climbs above that baseline, suspect a customs or documentation change (HS codes, commercial invoice data) rather than carrier failure. What exactly converts an exception into a failed delivery or a claim? Roughly a quarter to two-fifths of exceptions end in a genuine non-delivery; the rest recover (held parcels get collected, attempted-no-access succeeds on retry). Of the failures, lost and damaged parcels convert into insurance claims. So a 30-day exception count of 566 might yield 140 to 230 failures and a smaller number of claims. Track the chain via Failed Deliveries then Open Claims. Why does a parcel that eventually delivered still count as an exception? Because the card measures exception incidence, not standing exceptions. A parcel held at a facility for three days then delivered generated a customer-service ticket and a worse experience even though it arrived. Counting only currently-stuck parcels would understate the operational load. If you want a point-in-time “how many are stuck right now” view, filter EasyPost Trackers on current status instead. The dashboard shows a parcel as an exception but the card does not. Why? Two usual reasons. (1) Ingestion latency: the scan reached EasyPost but has not yet reached our index; it will appear within the normal refresh window. (2) Status mapping: EasyPost may classify that scan asin_transit with an exception note in status_detail rather than as a failure status, in which case the card does not count it. The card follows EasyPost’s normalised status, which is deliberately conservative.
Can I exclude weather and holiday backlogs from the rate?
No, and you should not want to. The card records actual exception incidence including weather and peak backlogs, because those still generate customer impact and CS load. What you can do is annotate known events and temporarily re-baseline the alert threshold for the affected window in Vortex IQ, then reset it when the network recovers. Do not permanently raise the threshold; the carriers should be held to baseline once the event passes.
How does this differ from the same card on a single-carrier connector like Australia Post or Royal Mail?
A single-carrier connector reads one carrier’s scans directly, so there is no blend and no normalisation layer to reconcile against. On EasyPost the dial is a weighted blend across every carrier your rate-shop used, which is more representative of total despatch health but means you must drop into the per-carrier breakdown to act. The threshold (>3%) and the exception definition are kept consistent so the cards read the same way side by side.