Event-Time vs Processing-Time in Fabric Real-Time Intelligence: Preventing Wrong Logistics KPIs

A logistics event — a GPS ping, a gate scan, a temperature reading — happens at one moment and reaches your platform at another. Event time is when it actually occurred, usually stamped by the device. Processing time is when the streaming platform received it. In a clean world those are nearly the same; in real logistics they are not.

Trucks drive through tunnels and dead zones and buffer their pings until signal returns. Handheld scanners sync in batches. Networks drop and recover. The result is a stream where events arrive late and out of order — an event that happened at 10:02 might land at 10:11, after an event that happened at 10:05. Both timestamps are correct; they just measure different things.

Which timestamp you build your KPI on is not a detail. It is the decision that determines whether the metric reflects what happened or merely what arrived, and those diverge precisely under the conditions — poor signal, congestion — that logistics operations most need to measure.

Take a simple metric: deliveries completed per hour, or on-time arrivals in the 9–10am window. Bucket events by processing time and a delivery that completed at 9:58 but whose event arrived at 10:07 counts in the 10–11am window. The 9–10 figure is understated, the 10–11 figure overstated, and neither reflects reality — purely because of network lateness that has nothing to do with the operation.

Dwell time and transit windows are worse. If the "arrived at depot" event is late and the "departed" event is on time, a processing-time calculation can show a negative dwell or a nonsensical duration, because the two timestamps bracketing the window came from different lateness. The KPI does not just shift — it can become incoherent.

And this corrupts the metric exactly when it matters most. Heavy congestion and poor-signal routes are both when operations most need accurate timing and when lateness is worst, so a processing-time KPI is least trustworthy under the conditions it is meant to illuminate. A dashboard that is wrong in the quiet periods and more wrong in the busy ones is not a dashboard anyone should act on.

The fix is to window and aggregate on event time — the device’s own timestamp of when the thing happened — not on when the platform received it. A delivery that completed at 9:58 then counts in the 9–10am window regardless of when its event arrived, so the metric reflects the operation rather than the network. This is the single most important choice in building any time-based streaming KPI.

In Microsoft Fabric Real-Time Intelligence, this means your Eventstream processing and the aggregations in the Eventhouse are built to bucket by the event’s own timestamp field, not the ingestion time. It is a deliberate design decision: the event-time column has to be identified, trusted, and used consistently as the basis for every time window, from the stream through to the KQL queries that power the dashboard.

It also assumes the device clocks are reasonable. Where device timestamps are unreliable or skewed, part of the design is reconciling or correcting them, because event-time windowing is only as good as the event times the devices report. That is a known piece of work on real telematics fleets, not an afterthought.

Event-time windowing raises an unavoidable question: if you are bucketing by when things happened, how long do you wait for late events before you consider a window complete? Wait too little and late events miss their window; wait too long and the metric is never final. This is the watermark decision — defining how late an event can be and still be counted into its proper window.

Set that lateness bound to the real behaviour of your fleet — how late pings genuinely arrive from dead zones and batching devices — so the normal lateness is absorbed. Then decide what happens to an event later than the bound: either it updates the already-reported window (a correction, so the 9–10am figure is restated when a very-late 9:58 event finally lands) or it is dropped as too late to matter, depending on whether downstream consumers can handle a restatement.

Out-of-order arrival is handled by the same mechanism: because you bucket by event time, an event that arrives after a later one still lands in its correct earlier window. The platform reorders by event time within the lateness bound rather than trusting arrival order. The design choice is explicit and worth stating in the pipeline — how late is allowed, and what happens beyond that — because leaving it implicit is how a KPI silently loses late data.

A real-time logistics KPI is only trustworthy if it is built on event time. Bucket by when events actually happened, not when they arrived; identify and trust the device timestamp as the basis for every time window; set a lateness bound to how late your data genuinely arrives; and decide explicitly whether very-late events restate a window or are dropped. In Fabric Real-Time Intelligence those are concrete choices in how the Eventstream and Eventhouse aggregations are designed.

The test is blunt: if a truck emerged from a tunnel and dumped ten minutes of buffered pings, would your on-time and dwell KPIs still be correct for the period those events belong to? If they would shift to the wrong bucket, the pipeline is windowing on arrival time and the dashboard is confidently wrong under exactly the conditions operations cares about. Get event-time windowing right and late data corrects itself into the period it belongs to — which is the whole point of a real-time metric you can act on.