Event Timing and Delays
A recurring question from teams comparing Dockflow against a terminal portal: the event happened at one time, but it appeared in Dockflow later. This page explains what the timestamps mean and which gaps are expected.
If your question is which of two conflicting values wins, see source precedence instead.
Two different timestamps
Every event carries two distinct times, and they answer different questions:
| Timestamp | Question it answers |
|---|---|
| Event time | When did the container actually move? |
| Received time | When did Dockflow learn about it? |
A gap between them is not an error in the event time. It is the reporting latency of whichever source published it.
The timestamp shown is the latest confirmation
Dockflow retrieves the same data repeatedly, so a single event is typically confirmed several times. The interface currently shows the most recent confirmation for an event rather than the first one.
This matters when you are measuring latency. An event first seen at 02:35 and re-confirmed at 09:00 displays the later time, which makes the reporting look slower than it was.
Showing both the first and the latest confirmation for an event gives a more accurate picture, and work is under way on that. The underlying event data is unaffected: vessel arrival events in particular are highly reliable, and this is a presentation question rather than a data question.
Measure from when the shipment entered Dockflow
Before concluding that an event arrived late, check when the shipment was created.
A shipment uploaded after the event already happened cannot have been reported earlier than its own creation. One reported case of an "8 hour delay" turned out to be 4 minutes: the shipment was uploaded at 13:55 and the discharge was reported at 13:59. The event itself had occurred earlier that morning, before Dockflow knew the shipment existed.
The creation date is shown at the top of the events section on the tradeflow.
Expected latency by source
Not all sources publish at the same speed, and the difference is structural.
Carrier feeds publish some events with significant delay. Gate-out in particular is often made available late by the carrier. When the only source for an event is the carrier, that delay is inherited and is normal.
Terminal and port community feeds are generally faster and are the preferred source where the terminal participates. If an event is available from the port community system but reaching you through the carrier instead, that is worth flagging, because it suggests the faster route is not being used for that shipment.
A delay can also originate at the terminal itself, between the physical move and the moment it is recorded digitally. That gap sits upstream of any data provider.
What counts as an outlier
A single slow event is hard to judge in isolation. What makes it assessable is the standard reporting time for that event type at that terminal, which is what the data quality metrics track.
Use freshness to see how regularly sources are checked, and confirmation delay for how long confirmations take. If a specific event is well outside the normal range, that is a genuine outlier worth raising.
Reading the freshness figure
Two properties of the freshness metric surprise people:
- It covers currently active tradeflows only. It describes how regularly Dockflow is checking sources right now, not a historical average. The number of data points therefore does not grow when you widen the time filter.
- Peaks are excluded from the averages. Enabling a new carrier integration can surface a large batch of events for past shipments at once. Those spikes are real but unrepresentative, so they do not drag the average.
You can click through in the dashboard to see the exact containers and events a figure is based on.