At a glance
A table of individual PostNord parcels that have gone silent: shipments whose last tracking scan is older than the expected interval for their current status, with no new event for longer than the gap threshold, in the trailing 24 hours. A gap means the parcel has stopped emitting scans while still in transit. Sometimes that is harmless ingestion lag; often it is a stuck, lost or stranded parcel, and a customer about to ask where their order is. Each row is one parcel you can chase before it becomes a refund.
Calculation
Calculated automatically from your PostNord data. See the At a glance summary above for what the table tracks and the worked example below for a typical reading.Worked example
The Stockholm outdoor-apparel brand. Reading taken at 09:00 CET on 18 Mar 26, evaluating parcels stale in the last 24 hours. The table shows 11 stale parcels:
Five things this list tells the operations lead:
- The two Hallsberg parcels are a cluster, not two coincidences. Both went silent at the same depot within 15 minutes of each other and have been quiet 35 hours. That is a sortation-hub signal: a missort batch, or a scanner outage at Hallsberg (Sweden’s largest terminal). One stuck parcel is bad luck; two at the same depot at the same time is an incident. Check Exception Rate for a
MISSORTrise on the SE account. - The Oslo customs row is the most urgent for the customer. 49 hours at
CUSTOMS_HELDfor a Norway cross-border parcel usually means missing or incomplete CN23 documentation. This will not self-clear; someone has to supply the customs data or the parcel gets returned. This is a where-is-my-order ticket waiting to happen, and a cross-border RTS waiting to happen, see Return Rate by PostNord Service Code. - The Finland
INFORMEDrow never got a first scan. The label was booked 43 hours ago and PostNord has no movement event. The parcel was probably never collected: it is sitting on the warehouse floor or was missed by the carrier pickup. This is the same parcel that would show as a breach on Orders with Dispatch SLA Missed. Physically find it today. - The Collect
OUT_FOR_DELIVERYrow at 14 hours is borderline. Last-mile silence has a tighter threshold (8 to 12 hours) because a parcel out for delivery should scan as delivered or as a failed attempt within the day. 14 hours silent suggests a missed delivery scan or a parcel that did not make it onto the round. Lower urgency than the customs row but worth a check. - The table is a worklist, not a dashboard. The aim is to clear it to zero each morning: chase the customs doc, find the floor-stranded parcel, raise a PostNord trace on the Hallsberg cluster. Every row resolved before the customer notices is a where-is-my-order ticket and a potential refund avoided. That is why it sits in the Revenue at Risk class.
Sibling cards merchants should reference together
The gap table is the daily operational worklist. Pair it with these to find the cause and size the downstream risk:Reconciling against the vendor’s own dashboard
Where to look in PostNord’s own portal: PostNord Business Portal → Shipments, then open each flagged consignment ID to view its full event timeline, or Reports → Tracking Events to scan last-event times in bulk. PostNord does not surface a “stale parcel” list of its own; you would have to sort the shipments list by last-event time and eyeball which ones have gone quiet. This card automates that sort and applies the status-aware threshold. The closest like-for-like check is: take each consignment ID from the table, open it in the portal, and confirm the last event time matches and that no newer event exists. Remember the portal shows scan timestamps in carrier-local time (CET / CEST), while the card normalises to UTC internally and shows both local and hours-ago in the table. Why our table may legitimately differ from the portal:
Cross-connector reconciliation:
Known limitations / merchant FAQs
A parcel shows on the table but PostNord’s portal has a newer scan than my last-seen time. Which is right? The portal, momentarily. PostNord delivers scans to its API in batches, so a parcel that physically scanned 20 minutes ago can still look silent to the card until that batch ingests. The card errs toward listing the parcel (better a false alarm you can dismiss than a stuck parcel you miss). If a row is on the table for one refresh and gone the next, it was ingestion lag. A row that survives several hourly refreshes is a genuine gap worth chasing. Why is the threshold different for different parcels? Because expected silence differs by status. A parcelIN_TRANSIT on a long line-haul leg can legitimately go quiet for a day or more between depot scans, so its threshold is wide (24 to 36 hours). A parcel OUT_FOR_DELIVERY should resolve to delivered or failed within the day, so its threshold is tight (8 to 12 hours). A flat threshold would either flood the table with normal line-haul silences or miss stuck last-mile parcels. The status-aware threshold targets the silences that actually matter.
The whole table just filled up at once. Are all these parcels really stuck?
Almost certainly not. A sudden mass-gap across many parcels is the tracking feed being down, not every parcel stopping at once. Check PostNord Tracking API Unavailable / 5xx first. If the API is erroring, the gaps are an artefact: no new scans are arriving for anything. Wait for the feed to recover and the table to drain before treating any row as a real stuck parcel.
A cross-border parcel has been silent 30 hours at customs. Is that a gap?
Maybe not yet. Cross-border thresholds are widened because customs dwell is a normal, legitimate silence, especially for Norway and Finland. A parcel quiet 30 hours at CUSTOMS_HELD may still be inside its widened window. But a parcel silent well past that window (the worked example’s 49-hour Oslo row) is flagged because it has exceeded even the customs allowance, and almost always means missing CN23 documentation that someone has to supply.
A label was booked but the parcel never got a first scan. Why is it here?
Because a booked-but-never-scanned parcel is the highest-value catch on this table: it means PostNord never received the parcel. It is sitting on your warehouse floor, or the carrier pickup missed it. This same parcel shows as a breach on Orders with Dispatch SLA Missed. Find it physically today: a never-collected parcel will eventually be cancelled or re-booked, and the customer is already waiting.
How should I work this table day to day?
As a worklist to clear to zero. Each morning: (1) dismiss the rows that self-cleared overnight (ingestion lag); (2) chase customs-held rows by supplying missing documentation; (3) physically locate any never-scanned rows; (4) raise a PostNord trace on any depot cluster (two or more parcels silent at the same hub). Resolving a row before the customer notices avoids a ticket and a possible refund, which is the entire point of catching the gap early.
Does a delivered parcel ever get stuck on the table?
No. The moment a terminal event (delivered, returned, cancelled) ingests, the parcel drops off the table. If a delivered parcel lingers, its delivered scan has not ingested yet (the same batching lag), and it will clear on the next refresh. The table only ever holds parcels in a non-terminal status.