At a glance
Count of EasyPost-routed parcels in the last 7 days whose tracking ended in a genuine non-delivery: undeliverable address, refused, lost, damaged beyond delivery, or returned to sender. This is the subset of exceptions that did not recover. It is the workload number for the customer-service and claims teams, and it alerts when failures exceed 2 percent of total parcels.
What it tracks
Grounded in the card’sdetail (“Failed Deliveries for the selected period.”) and its >2% of total alert: the card reads EasyPost Tracker objects (GET /v2/trackers and the tracker.updated webhook) over the trailing 7 days and counts those whose final normalised status is a non-delivery, principally failure and return_to_sender, plus parcels stale past their estimated delivery date with no further movement. Unlike Exception Rate, which counts any parcel that ever threw an exception (including ones that recovered and delivered), this card counts only the parcels that genuinely did not reach the customer. The two are linked: today’s exceptions are the leading indicator, and roughly a quarter to two-fifths of them convert into a failure here over the following days. The count is blended across every underlying carrier the rate-shop used, so when it breaches the >2% of total line, open OTD by Underlying Carrier to find which carrier is driving it. Failures cascade: lost and damaged parcels become Open Claims and Claim Value (open), and undeliverable parcels become Returned to Sender. Each failure also typically generates a refund or reship, so a spike here predicts a refund-rate rise downstream.
Reconciling against the source
Cross-check against the EasyPost dashboard under Logs → Trackers filtered tofailure and return_to_sender over the same 7 days, and against each underlying carrier’s portal for the authoritative final scan. Differences come from tracking-event ingestion latency (a failure scanned an hour ago may not show yet) and from scan timestamps recorded in carrier-local time while the card windows in UTC.