.png)
Container tracking becomes useful when each event leads to an owner, an expected next event and an escalation condition. Do not treat a timeline as a guaranteed ETA. Preserve whether a timestamp is planned, estimated or actual; identify whether the event concerns the shipment, equipment or transport movement; then reconcile it to the booking and operational plan.
DCSA Track & Trace establishes standardised event definitions and data exchange across the container journey. Its current Track & Trace 2.2 documentation covers pre-shipment, pre-ocean, ocean, post-ocean and post-shipment phases. A carrier portal may expose only part of that model and may use additional carrier-specific labels.
Start with the controlled shipment plan
Before reading events, store:
- booking number, bill of lading number and container number;
- carrier, forwarder and relevant operational contacts;
- origin, port of loading, any transshipment port and port of discharge;
- service, vessels and voyages where confirmed;
- planned cut-offs and cargo handover;
- estimated departure and arrival basis;
- Australian clearance, availability, delivery and empty-return owners; and
- the date and source of the plan.
Tracking must be compared with that baseline. The ocean booking cut-off checklist owns the pre-sailing deadlines, while the sea-freight transit-time guide owns elapsed-time planning. This article owns observed events and exceptions after the plan exists.
Keep planned, estimated and actual times distinct
The DCSA shipping glossary distinguishes planned events, later estimates and actual completion timestamps. Build separate fields rather than one overwritten date column.
| Time qualifier | Meaning for the control board | Safe use |
|---|---|---|
| Planned | Original or confirmed plan at the declared point | Baseline comparison |
| Estimated | Current prediction that can change | Resource planning with uncertainty |
| Actual | Reported completion of the event | Evidence that a stated milestone occurred |
An actual vessel departure does not prove the container was loaded unless the relevant container/equipment event also supports that conclusion. An estimated arrival is not an actual discharge or cargo-availability event.
Classify the event before interpreting it
A useful board separates three questions:
- Shipment/document: what has happened to the commercial shipment or document process?
- Equipment: where is the container and what physical handling event occurred?
- Transport: what happened to the vessel, truck, rail or other transport movement?
Do not flatten those layers into a generic in transit status. The owner and next action differ.
For example, a vessel may depart while a specific container remains behind. Conversely, a container gate-in event does not prove export customs, loading or vessel departure.
Use a milestone sequence, not a universal label map
Carrier terminology varies, but an importer can maintain a qualified sequence:
- booking or shipment plan confirmed;
- empty equipment released or picked up, where relevant;
- laden container gated in or cargo received;
- loaded on the planned or revised vessel;
- vessel departed the load port;
- transshipment discharge and onward load, when applicable;
- vessel arrived at the discharge port;
- container discharged;
- import clearance and cargo availability confirmed through the relevant sources;
- container or cargo collected; and
- empty container returned for FCL.
This is an operational framework, not a promise that every portal will show every step or use these exact words.
Build the exception board
| Current evidence | Expected next evidence | Owner | Review time | Escalate when |
|---|---|---|---|---|
| Booking confirmed | Empty release or cargo handover | Supplier/forwarder | Before origin cut-off | Handover evidence missing |
| Laden gate-in | Load confirmation and departure | Forwarder/carrier | After cut-off | Container not linked to planned voyage |
| Vessel departed | Arrival estimate and connection status | Carrier/forwarder | On material ETA change | Estimate disappears or connection at risk |
| Transshipment discharge | Onward load and departure | Carrier/forwarder | Before onward sailing | No onward confirmation by agreed checkpoint |
| Vessel arrived | Container discharge | Carrier/terminal channel | After berth/operations | Container event missing beyond agreed tolerance |
| Container discharged | Availability, clearance and pickup | Broker/forwarder/importer | Daily until ready | Holds or charges lack owner |
| Gate-out full | Delivery and empty return | Transport/importer | Before free-time deadline | Return plan or proof missing |
Set review times from the shipment and provider context. Do not publish one universal number of hours after which every missing event means failure.
Investigate missing or conflicting events
When the next milestone is missing:
- confirm the identifiers and that the portal covers the relevant carrier or leg;
- compare the booking, carrier and forwarder views;
- distinguish a missing data update from a missing physical event;
- ask for the exact vessel, voyage, location and event qualifier;
- retain screenshots or exported evidence with retrieval time where useful; and
- record who is confirming the operational state.
Maersk tracking is one example of a carrier tracking entry point. It is not a universal source for shipments carried or controlled elsewhere. Use the contracted carrier and forwarder channels for the actual booking.
Do not invent a cause such as customs delay, rollover or congestion merely because an ETA moved. Record cause unconfirmed until a credible source provides it.
Treat transshipment as two controlled ocean legs
For a via service, retain:
- actual discharge from the first vessel;
- planned and estimated onward connection;
- actual load to the onward vessel;
- actual onward departure; and
- revised final arrival estimate.
The direct-versus-transshipment route comparison once live owns the pre-booking architecture. Tracking owns whether the booked connection is occurring as planned.
A vessel arrival at the hub is not enough. The container needs its own connection evidence.
Connect arrival events to Australian readiness
Do not wait for discharge to discover that clearance, transport or empty-return ownership is unclear. Before arrival, confirm:
- commercial documents are complete;
- customs and biosecurity work is with the appropriate party;
- destination charges and release conditions are understood;
- delivery capacity and access constraints are known;
- cargo availability will be checked through the correct channel; and
- the empty-container return plan is current for FCL.
Vessel arrival, container discharge, customs clearance, cargo availability and terminal release are distinct milestones. Do not label the shipment ready on vessel arrival alone.
Preserve a useful event log
For each material update, store:
- event label exactly as received;
- normalised internal milestone, if used;
- shipment/equipment/transport category;
- planned, estimated or actual qualifier;
- event time and time zone;
- location and facility where supplied;
- source and retrieval time;
- expected next event;
- owner and action; and
- escalation outcome.
Never overwrite the prior estimate. Keeping revisions shows when the plan changed and whether downstream actions were updated.
Close the shipment with evidence
After delivery, confirm the event record reconciles to transport documents, arrival, release, pickup and delivery evidence. For FCL, retain the gate-in or dehire evidence required by the operational process. Record unresolved charges or claims separately rather than editing the tracking history.
The immediate next step is to choose one live shipment and build the board from its booking. If the current tracking view cannot answer what happened, what should happen next, who owns it and when to escalate, the portal is being observed—not managed.