Two providers looked at Shanghai in the same week last month and published waiting times four days apart. Nobody was wrong. They were measuring from different events, and neither of them said so on the chart.
This is the most common way a logistics dashboard misleads a competent person: not by carrying bad data, but by carrying good data whose definition is buried.
Four clocks, all of them called "waiting time"
Anchorage time starts when a vessel drops anchor in the designated area and ends when it weighs anchor. It is easy to derive from AIS and it is the most commonly published figure. It also counts ships that are anchored deliberately — waiting for cargo readiness, for a tide, for a documentation issue — as congestion.
Berth wait starts at arrival in the port limits and ends when the vessel is alongside. It is the number that actually maps to your delay, and it is harder to compute because it requires knowing the port limit polygon and the berth position, not just the ship's track.
Port stay is arrival to departure, so it includes the working time. A port with fast cranes and a long queue and a port with slow cranes and no queue can produce the same port stay and mean opposite things operationally.
Notice of readiness to berth is the charterparty definition. It is the one your legal team cares about and it appears in almost no dashboard.
When a figure moves from ten days to six between two sources, the first question is never "which is right". It is "which event starts the clock".
Why AIS makes this worse rather than better
Nearly every congestion product is built on AIS, and AIS is a position feed, not a status feed. It tells you a ship is stationary at a coordinate. It does not tell you why.
So every provider layers inference on top: a geofence to decide whether that coordinate counts as the anchorage, a speed threshold to decide whether the vessel is waiting or merely slow, a dwell minimum to filter out ships pausing for a pilot. Those three choices are the product. Change the geofence radius and your congestion figure changes by days, with no change in the world.
The effect compounds at ports where the anchorage is large or split, which is precisely where congestion is worst. At the start of September something like 3.92m TEU was in queues globally with North Asia carrying 54% of it — and North Asia is where anchorage geography is most ambiguous.
Reception coverage is the other one. AIS gaps over open water get filled by satellite passes at intervals, and a vessel that appears to sit still for six hours may simply not have been seen. Interpolation across that gap is a modelling choice too.
Comparing two sources without fooling yourself
Ask for the definition before you ask for the number. Any provider who cannot tell you the start event, the end event and the filter thresholds is selling you a chart rather than a measurement.
Then compare the same series to itself over time rather than comparing two series to each other. A provider whose methodology is consistent will show you the trend correctly even if their absolute level is two days off someone else's. Trend is what you make decisions on; level is what you argue about in meetings.
And always pair the congestion figure with something observed rather than inferred. Berth events from a terminal feed, gate timestamps, actual discharge milestones — these are facts, and one fact anchors a page of inference. That is the reason our port pages put the actual call record next to the queue view rather than showing the queue alone, and why container tracking marks which milestones are actuals and which are estimates.
One caveat I would apply to my own argument: observed data is not automatically better. A terminal feed that publishes a berth event when a job is opened in the system rather than when the ship is alongside is also an inference, just one that happens inside somebody else's software where you cannot see it.
If you are building an internal dashboard on any of this, write the definition into the chart title. It is the cheapest thing you will ever do to stop a good decision being made on a misread number.
