Container cycle time is the one logistics metric almost every plant quotes and almost none measures. The reason is a subtle identity problem rather than a tracking problem. Automotive labelling has become genuinely excellent — the Global Transport Label carries a unique licence plate combining an organisation code and serial number, globally unique within a year, and that number enables continuous package tracking through the whole transport chain. But it identifies the package, the handling unit that exists from despatch until unpacking. It does not identify the steel rack underneath, which will outlive several thousand of those package numbers. So plants end up with excellent shipment traceability and no asset traceability, and cycle time gets estimated by dividing pool size by monthly trips — a calculation that cannot show you where the days actually go. Request an enterprise demo to see stage-level cycle time on your own containers.
2026 GUIDE · CYCLE TIME MEASUREMENT
Container Cycle Time Measurement and Recovery
Cycle broken into stages with a clock on each, dwell separated between supplier and plant, stagnation alerted before a unit is written off, and recovery workflows that actually retrieve assets rather than reordering them.
A transport label identifies the shipment. It does not identify the asset.
Everything difficult about cycle time measurement follows from that one sentence.
Six Stages, Six Clocks
A cycle is not one duration. It is six, with different owners and different failure modes, and only a stage-level breakdown tells you which one to attack. Aggregate cycle time tells you the loop is slow; it never tells you where.
← Swipe to see all columns →
Note that two of the six stages sit entirely outside your plant and two sit entirely inside it. Plants that measure only what happens between gate-in and emptying are measuring roughly a third of the cycle — and it is generally not the third where the delay lives.
Package Identity Versus Asset Identity
These are two different tracking problems and they need two different mechanisms. Conflating them is why so many container programmes have rich data and no cycle time.
Package identity — the label
A unique licence plate of organisation code plus serial number, scannable from a single barcode field
Globally unique within one year, enabling the single-document principle across the transport chain
Content must match the EDI messages and the delivery note
Identifies each individual container and handling unit for that shipment
Ceases to mean anything once the unit is unpacked
Gives you: shipment traceability, receipt matching, no relabelling. The GTL replaced the earlier Odette transport label and VDA 4902 for exactly these reasons.
Asset identity — the container
A persistent identifier fixed to the physical unit for its whole service life
Survives hundreds of trips, several part numbers and multiple suppliers
Carried by RFID, a durable asset plate, or a permanent serial marking
Independent of what is inside it or where it is going
The only thing a cycle can actually be measured against
Gives you: cycle time, dwell by stage, loss attribution, stagnation detection. Nothing else can.
The pragmatic middle path
Full asset instrumentation of every container is rarely justified at once. Instrument the highest-value types first, and for the rest derive a statistical cycle time by linking successive package numbers through the same container type and lane — less precise, available immediately, and enough to identify which stage is bleeding days. Precision matters less than knowing which of the six clocks is the problem.
You do not need to instrument the whole fleet to find out where the cycle breaks.
An enterprise demo shows stage-level cycle time derived from data you already produce — gate events, receipt postings, collection records and package numbers — and where asset-level identity would pay for itself.
The Two Dwell Pools
Dwell at the supplier and dwell at the plant behave differently, are caused differently and are fixed differently. Reporting a single dwell figure guarantees the wrong intervention.
Dwell at the supplier
Typical causeEmpties held deliberately as a private buffer against your collection unreliability
How you see itOnly through the supplier's own reporting, or by the gap between your despatch and their next fill
FixReliable collection cadence first, then a contracted return deadline. In that order — a deadline against unreliable collection is unenforceable
Watch forSuppliers accumulating a hidden reserve, which inflates the pool requirement network-wide
Dwell at the plant
Typical causeEmpty collection treated as housekeeping rather than as part of the milk run stop
How you see itDirectly, from the emptied event to the collection event — if both are recorded
FixMake empty removal part of the delivery stop, and reconcile empties collected against full containers delivered per cycle
Watch forEmpties occupying yard positions that inbound volume needs, which reads as a yard problem
Stagnation Alerts
A stagnant container is not lost, and treating the two the same is expensive — one needs a phone call, the other needs a replacement purchase. Alert per stage against that stage's own expected duration, never against total cycle time.
Level 1
Stage overrunA unit exceeds the expected duration for its current stage. Informational, aggregated, reviewed weekly — individual overruns are normal noise.
Level 2
StagnantSubstantially past expected duration with no state change. Actionable: a named owner contacts the holding location. Most Level 2 units come back.
Level 3
UnseenNo event recorded anywhere for an extended period. Not yet lost, and this is the population where shrinkage silently accumulates before anyone writes it off.
Level 4
Presumed lostWritten down and removed from the pool count. Must be a deliberate decision with a date, or the pool size on paper drifts permanently away from the pool that exists.
Level 3 is where the money is
Most programmes have only two states — in use and lost — which means every unit spends an indefinite period in an unmeasured limbo before someone gives up on it. Making unseen an explicit state with a threshold and an owner converts a quiet write-off into a recovery attempt, and recovery is an order of magnitude cheaper than replacement.
Recovery Workflows
Four workflows, matched to the reason the unit stopped moving. Applying one workflow to all cases is why recovery programmes produce activity without results.
A
Known location, awaiting collection
The commonest case by a wide margin. The unit is exactly where it should be and nobody scheduled a pickup.
WorkflowAdd to the next scheduled return leg. No escalation, no contact — this is a routing task, not an incident.
B
Known location, wrong location
Drifted to a site with no consumption for that container type. Structural imbalance rather than an individual failure.
WorkflowBatch into a rebalancing move. Record the lane so the drift pattern becomes visible rather than being corrected repeatedly.
C
Location unknown, partner known
Last seen at a supplier or recipient who cannot currently locate it. Where contracted return obligations earn their place.
WorkflowFormal query against the return deadline, with the replacement value stated. Escalate on the second cycle, not the first.
D
Location unknown, partner unknown
No event trail. Only genuinely unavoidable in open loops with changing recipients — in a closed loop it means the event capture has a gap.
WorkflowWrite off on a stated schedule, and investigate the capture gap rather than the unit. The next hundred will go the same way.
Where Cycle Events Come From
Most of the six clocks can be closed with events you already generate. Start here before instrumenting anything.
Despatch advice and package numberCloses fill and despatch prep. The licence plate is assigned here, and it anchors the shipment to a date.
Gate check-inCloses inbound transit. Already captured at most plants and rarely connected to container identity.
Goods receipt postingA weak proxy for arrival at the rack, since it records a posting rather than a physical position. Use it only if nothing better exists.
Point-of-use consumption scanCloses plant dwell full and opens plant dwell empty — the single most valuable event for cycle measurement and the one most often absent.
Empty collection scanCloses plant dwell empty. Scanned rather than counted, or the identity chain breaks at exactly the point you need it.
Supplier fill confirmationCloses the loop. Requires partner data sharing, which is a contractual matter before it is a technical one.
Enterprise demo
See stage-level cycle time on your own containers
We take your gate events, receipt postings, collection records and package numbers, and reconstruct the six clocks for your priority container types — showing which stage holds the days, what the two dwell pools look like separately, and where asset-level identity would change the answer. Odette and GTL labelling supported natively.
What to Measure
Six figures, all per container type. A fleet-wide average is the number that lets every specific problem hide. Our analytics and reporting module carries them.
Cycle time by stageAll six clocks, reported separately. The whole point of the exercise — a total tells you nothing you can act on.
Cycle time at the 90th percentileAlongside the median. Long-tail units are what force pool expansion, and averages are structurally blind to them.
Plant empty dwellEmptied to collected. Entirely within your control, usually the largest single stage, and the cheapest to improve.
Units by stagnation levelCounts at levels one to four, with movement between them. Rising Level 3 population predicts next quarter's write-off.
Recovery success rate by workflowShare of units retrieved, split A through D. Tells you whether recovery effort is landing where it can work.
Event coverage per cycleHow many of the six clocks you can actually close. The honest measure of whether your cycle time is measured or estimated.
Frequently Asked Questions
Can the transport label be used to measure cycle time?
Partly, and it is worth being precise about the limit. The Global Transport Label carries a licence plate combining organisation code and serial number, globally unique within a year, which enables continuous package tracking through the transport chain and removes the need for relabelling — excellent for shipment traceability. But it identifies the handling unit for that shipment, not the physical container, so once the unit is unpacked the identity ends. Cycle time needs an identifier that persists across hundreds of trips, which means an asset tag rather than a shipping label.
Do we need RFID on every container?
No, and attempting it usually stalls the programme. Instrument the highest-value types first, where the capital case is clear, and for everything else derive a statistical cycle time by linking successive package numbers through the same container type and lane. That is less precise than asset-level tracking and entirely sufficient to identify which of the six stages is holding the days — which is the decision you actually need to make before spending anything on hardware.
Which stage usually holds the most time?
Plant empty dwell and supplier awaiting-fill, in most loops. Both are caused by collection unreliability rather than by transport or handling, and both are invisible in a single blended dwell figure. The plant side is the better starting point because it is entirely within your control: making empty removal part of the delivery stop, and reconciling empties collected against full containers delivered per cycle, typically recovers days without touching a supplier agreement.
Why separate supplier dwell from plant dwell?
Because they have opposite fixes. Plant dwell is a collection scheduling problem you can solve directly. Supplier dwell is usually deliberate — the supplier holding empties as a private buffer against your collection unreliability — so imposing a return deadline before fixing your own cadence produces a dispute rather than an improvement. Sequence matters: make collection reliable, then contract the deadline, then measure compliance per partner.
What threshold makes a container stagnant?
Set it per stage against that stage's own expected duration, not against total cycle time. A unit five days into a stage that normally takes one is stagnant; the same five days inside a stage that normally takes seven is unremarkable. Use four levels — overrun, stagnant, unseen, presumed lost — because the middle two are where recovery is still possible and most programmes collapse them into a single ambiguous state that nobody owns.
Is recovery actually worth the effort?
For the majority of stagnant units, yes, because most of them are simply sitting somewhere known with no collection scheduled — a routing task rather than an incident. Recovery is far cheaper than replacement, and the effort concentrates on workflows A and B where the location is known. What is not worth pursuing is workflow D, where there is no event trail at all: write those off on a stated schedule and investigate the capture gap instead, because the next hundred units will disappear the same way.
What is the realistic first step?
Count how many of the six clocks you can currently close from existing data. Most plants find they can close three or four, and that the missing ones cluster around consumption and empty collection — which is also where the delay lives. Adding a scan at empty collection is usually the single highest-value change, because it closes the largest stage and creates the identity chain the rest of the measurement depends on. Our
integrations overview covers the event sources.
Measure the Stage, Not the Loop
Six clocks reported separately, supplier and plant dwell kept apart, stagnation escalated through four explicit levels, and recovery matched to why the unit stopped moving rather than to a single generic process.
Works with GTL and Odette labelling · Uses existing gate and receipt events · Site-level configuration