At a glance
A live table of in-transit Bring shipments that have gone silent: no new tracking event for longer than the expected scan interval, inside the trailing 24 hours. A parcel with no fresh scan is a parcel you cannot see, and a silent parcel is the single best leading indicator of a delivery failure, a lost parcel, or a tracking-feed outage. Each row is one stale consignment with its last-known state.
| What it lists | One row per in-transit Bring consignment whose most recent tracking event is older than the staleness threshold for its stage, evaluated over the trailing 24 hours. Columns surface the consignment number, Bring product code, last event type, last event timestamp (carrier-local), hours since last scan, destination, and the linked order. |
| Data source | The Bring Tracking API (GET /tracking/api/v2/tracking) event stream per consignment, joined to the outbound booking from the Bring Booking API and the originating store order. The card compares each consignment’s latest event timestamp against now. |
| Cross-channel join | Stale shipments are listed regardless of sales channel; each row links back to its order so a marketplace parcel and a D2C parcel are triaged on one screen. |
| Staleness logic | The expected gap depends on the stage. A parcel mid-transit between Norwegian terminals should scan every few hours; a parcel at a Mypack pickup point legitimately sits with no movement until collected (those are excluded from “stale” and handled on the Mypack cards). The threshold is tuned per product and stage so a normal pause does not raise a row. |
| Bring product scope | All in-transit outbound Bring products. Delivered, collected and returned consignments drop off the list; only live, in-flight parcels can be stale. |
| Time window | 24H. This is a real-time triage table refreshed continuously, scoped to the last 24 hours so it shows what is actionable right now, not historical gaps. |
| Alert trigger | >0 stale. Zero-tolerance: any single silent in-transit parcel is one customer about to ask “where is my order”, so the alert fires on the first stale row. |
| Roles | owner, operations |
Calculation
For every live Bring consignment, the card reads the event list from the Bring Tracking API, takes the most recent event timestamp, and computes the gap tonow. If the gap exceeds the expected scan interval for that consignment’s current stage, the parcel is flagged stale and added as a row.
The “expected interval” is the key piece of logic. A parcel that has just been booked but not yet collected has a different normal silence than a parcel mid-line-haul or one out for delivery. A Mypack parcel waiting at a pickup point is supposed to be still, so the card does not treat pickup-point dwell as a gap; that is tracked separately on the Mypack expiry cards. The threshold is set per product code and per stage so the table surfaces genuine anomalies, not expected pauses.
All event timestamps arrive in carrier-local time (Norwegian time for NO-origin parcels). The card stores in UTC and renders the “hours since last scan” column against your display timezone, so the staleness figure is consistent regardless of where you read it. Because the Tracking API itself has ingestion latency, the card is conservative: a parcel that scanned 20 minutes ago but whose event has not yet propagated will not be wrongly flagged once the next sync lands.
Calculated automatically from your Bring tracking data. See the At a glance summary above and the worked example below.
Worked example
The same Oslo outdoor-apparel brand, around 1,900 outbound orders per week on Bring. Reading taken at 09:00 CET on 14 Apr 26; the table reflects the trailing 24 hours.| Consignment | Product code | Last event | Last scan (CET) | Hours stale | Destination |
|---|---|---|---|---|---|
| 70 7195 1234 5678 | Pakke levert hjem (5800) | In transit, Oslo terminal | 13 Apr 26 02:10 | 30.8 | Tromso, NO |
| 70 7195 2234 5679 | Pakke til hentested (5000) | Recipient notified | 12 Apr 26 18:40 | 38.3 | Bergen, NO |
| 70 7195 3234 5680 | Nordic export (SE) | Export, customs hold | 12 Apr 26 22:05 | 34.9 | Gothenburg, SE |
| 70 7195 4234 5681 | Pakke levert hjem (5800) | In transit, Trondheim | 13 Apr 26 06:30 | 26.5 | Bodo, NO |
>0 stale is tripped. Five things to notice:
- The Tromso row is the classic long-haul gap, but 30 hours is too long. A Pakke levert hjem parcel to northern Norway will have legitimate multi-hour gaps between terminal scans, but 30 hours with no movement after an Oslo-terminal scan is anomalous. This is the parcel to chase with Bring first; it may be mis-sorted or stuck.
- The Bergen Mypack row is a different story. “Recipient notified” means the parcel reached the pickup point and the customer was told. 38 hours of silence after that is normal dwell, the customer simply has not collected yet, so this row may be a tuning artefact rather than a true gap. Cross-check Mypack Pickup Expiry Rate; if dwell is expected at this stage it should not be on the gap list.
- The Gothenburg export row is a customs hold, which is a real, explainable gap. The last event is “customs hold”, so the parcel is genuinely stuck at the border, not lost. This is actionable: it needs a customs document chase. Pair with NO Export Customs Clearance Rate; a hold here is exactly the kind of friction that card aggregates.
- A whole-table spike is a feed problem, not 50 lost parcels. If this table jumps from 4 rows to 200 in one refresh, the likely cause is the Bring Tracking API being slow or down, not 200 parcels simultaneously going missing. Check Bring Tracking API Unavailable / 5xx before dispatching anyone to chase parcels; a feed outage makes every live parcel look stale at once.
- This is revenue at risk you can act on within the hour. Each stale row is a parcel that, if genuinely stuck, becomes a WISMO ticket, a refund, or a claim. Catching it while it is still in-flight lets you intervene (chase Bring, reship, pre-empt the customer) before it becomes a Failed Deliveries or Open Claims entry days later.
Sibling cards merchants should reference together
The tracking-event gap table is a real-time triage tool. Pair it with these to tell a real gap from a feed artefact and to size the downstream cost:| Card | Why pair it with Tracking-Event Gap | What the combination tells you |
|---|---|---|
| Bring Tracking API Unavailable / 5xx | A feed outage makes every live parcel look stale. | If this card spikes at the same time as the API card, the parcels are fine and the feed is down; do not chase. |
| NO Export Customs Clearance Rate | Export rows often stall at customs. | A customs hold is an explainable gap, not a lost parcel; the clearance card tells you if it is a one-off or a pattern. |
| Mypack Pickup Expiry Rate | Pickup-point dwell can look like a gap. | A “recipient notified” parcel sitting still is normal until expiry; this card tells you whether dwell is the real risk. |
| Exception Rate | Gaps often precede exceptions. | A parcel silent now frequently throws an exception in the next 24 to 48 hours; the gap is the early warning. |
| Failed Deliveries | Downstream outcome of an unresolved gap. | A stale parcel that never recovers becomes a failed delivery; chasing gaps reduces this count. |
| Open Claims | Lost parcels become claims. | A genuinely missing stale parcel is a claim in waiting; resolving it early avoids the claim. |
| Orders with Dispatch SLA Missed | The despatch-end companion. | This card catches parcels that go silent in transit; that card catches orders that never shipped on time. Together they cover both ends of the journey. |
Cross-connector: shopify.refund_rate | Downstream impact. | Unresolved gaps drive WISMO tickets and refunds at a few days lag. |
Reconciling against the source
Where to look in Bring’s own tooling: Bring Tracking for the per-consignment event history (enter the consignment number to see the full scan list and the last event), and Bring Mybring → Shipments → Shipment list to see the same consignments with their latest status and to filter for parcels stuck in a given state. The Tracking API that feeds this card is the same source the public tracking page reads, so the last event you see on tracking.bring.com should match the last event on the row, allowing for ingestion lag. The closest like-for-like check is: take a flagged consignment number, open it on tracking.bring.com, and confirm the last event timestamp matches the card’s “last scan” column. If the public page shows a newer event than the card, the difference is ingestion latency and will clear on the next sync. Why our number may legitimately differ from the public tracking page:| Reason | Direction | Why |
|---|---|---|
| Tracking-event ingestion lag | Ours can lag | The Bring Tracking API surfaces scans within minutes to a few hours of the physical event. A parcel that scanned recently may still show as stale here until the event propagates; the public page may update first. This is the most common source of a false-positive row. |
| Carrier-local scan timestamps | Display only | Bring stamps scans in Norwegian local time. The card converts to your display timezone for the “hours stale” figure; the public page shows local time. Compare the same clock when reconciling. |
| Staleness threshold tuning | Ours can flag dwell | Pickup-point dwell and customs holds are legitimate pauses. If a row looks normal on the public page (parcel waiting to be collected), the threshold for that stage may need tuning so expected dwell stops raising a row. |
| API outage | Ours higher | If the Bring Tracking API is returning 5xx errors, every live parcel goes silent in our index at once and the table fills with false rows. Reconcile against Bring Tracking API Unavailable / 5xx before acting. |
| Consignment state transition | Ours can lag | A parcel that just delivered drops off this list only once the delivered scan ingests; for a short window it may still appear as a live stale parcel. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
shopify.unfulfilled_orders | Upstream input; an order with no consignment cannot be a transit gap. | An order stuck before booking shows on the Shopify card, not here; here is transit-only. |
shopify.refund_rate | Downstream impact of unresolved gaps. | Refunds have many drivers; a transit gap is one early input. |