Shipments with Tracking-Event Gap, Bring

Shipments with Tracking-Event Gap for Bring stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Cross-Platform: Revenue at Risk

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-platform 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 to now. 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

The table lists 4 stale shipments. The alert at >0 stale is tripped. Five things to notice:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Cross-connector reconciliation:

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.

---

Known limitations / merchant FAQs

A parcel on the list looks fine when I check Bring tracking. Why is it flagged? Almost always ingestion latency. The Bring Tracking API surfaces scans minutes to hours after the physical event, so a parcel that scanned recently can still read as stale here until the event lands in our index. If the public page shows a newer event than the row, it will clear on the next sync. If it persists for several hours past a fresh public scan, raise it.

The whole table jumped from a handful of rows to dozens. Are all those parcels lost? Almost certainly not. A sudden whole-table spike is the signature of a Bring Tracking API outage: every live parcel goes silent in our index at once because no scans are arriving. Check Bring Tracking API Unavailable / 5xx first. Do not send anyone to chase parcels until you have ruled out a feed problem.

Why is a Mypack parcel at a pickup point showing as a gap? A “recipient notified” Mypack parcel legitimately sits still until the customer collects it, so it should not normally be flagged. If it is, the staleness threshold for the pickup stage needs tuning. Pickup-point dwell is tracked on Mypack Pickup Expiry Rate, not here; this card is for unexpected silence in active transit.

A customs hold is showing as a gap. Is that wrong? No, that is a real, explainable gap. A parcel held at customs is genuinely not moving, and you should act on it (chase the customs document). The difference from a lost parcel is that the last event tells you why it stopped. Pair with NO Export Customs Clearance Rate to see if it is a one-off or a pattern.

Why a 24-hour window and not longer? This is a real-time triage table: it shows what is actionable now. A parcel silent for days is no longer a fresh gap, it is a failed delivery or a claim, and lives on Failed Deliveries and Open Claims. The 24-hour scope keeps the table to parcels you can still save.

Does the staleness threshold differ by product? Yes. A line-haul parcel between Norwegian terminals should scan every few hours; an export parcel crossing a border legitimately has longer gaps; a pickup-point parcel is supposed to dwell. The threshold is set per product code and per stage so a normal pause does not raise a false row.

What is the playbook when a row is a genuine gap? In order: (1) confirm it is not a feed artefact by checking the public tracking page and Bring Tracking API Unavailable / 5xx; (2) read the last event type, a customs hold or pickup dwell is explainable, a mid-transit terminal scan with no follow-up is not; (3) for an unexplained mid-transit gap, chase Bring with the consignment number via Mybring; (4) pre-empt the customer with a proactive update before they raise a WISMO ticket; (5) if the parcel cannot be located, start the claim early on Open Claims rather than waiting for the customer.

---

Tracked live in Vortex IQ Nerve Centre

Shipments with Tracking-Event Gap is one of hundreds of KPI pulses Vortex IQ tracks across Bring and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.