How to calculate average latency per device in Real-Time Analytics

João Barros 14 de September de 2026 4 min read

This tutorial shows how to calculate average latency per device in Real-Time Analytics, useful to monitor performance and detect degradations. The technique aggregates events by time windows, handles late arrivals and produces metrics ready for alerts or dashboards.

Prerequisites

Account with access to a real-time ingestion service (e.g., Event Hubs, Kafka) and to a query/streaming engine (e.g., Azure Stream Analytics, Azure Data Explorer / Kusto).
Event source with fields: device_id, event_id, event_time (timestamp), processed_time (timestamp) and payload.
Basic knowledge of KQL or streaming SQL, and access to the environment to run queries.

Step 1: Why calculate average latency per device

Measuring latency (difference between event_time and processed_time) per device allows identifying network issues, devices with clocks out of sync or pipeline congestion. The average per window stabilizes variations and highlights trends.

Step 2: Define the metric and the window

Decide the definition: latency = processed_time - event_time (in milliseconds). Choose a tumbling or sliding window (for example, 1-minute tumbling) for real-time metrics. A window that's too short increases noise; too long loses resolution.

Step 3: Ingest events and calculate latency (KQL example)

Example in Kusto (Azure Data Explorer) to calculate latency in ms per device_id in 1-minute windows, ignoring events with significant negative latency and limiting allowed lateness to 2 minutes.

Events
| where ingestion_time() > ago(1h)  // ajustar conforme necessário
| extend event_time = todatetime(event_time), processed_time = todatetime(processed_time)
| extend latency_ms = datetime_diff('millisecond', processed_time, event_time) * -1
| where latency_ms >= 0 and latency_ms < 300000   // filtrar latências inválidas e >5min
| summarize avg_latency_ms = avg(latency_ms), p95_latency_ms = percentile(latency_ms, 95), count = count()
    by device_id, bin(event_time, 1m)
| order by event_time desc, device_id

Brief explanation of what each step does: convert timestamps, calculate latency_ms, filter anomalous values and aggregate by device_id and 1-minute window with avg and percentile for context.

Step 4: Handle late arrivals and adjust results

Late arrivals can distort windowed metrics. In AZURE DATA EXPLORER you can use ingestion_time policies or lateness tolerance; in Azure Stream Analytics use event-time and Late Arrival Policy. Alternative: maintain two aggregations — an initial one and a final one with a late-processing window (e.g., wait 2 minutes) and reconcile.

Step 5: Calculate moving average to smooth noise

To get a more stable evolution, apply a moving average over the windows. In KQL you can use make-series for time series or simple prev/next functions for continuous windows.

// Exemplo simples de média móvel de 5 janelas de 1m
Events
| extend event_time = todatetime(event_time), latency_ms = datetime_diff('millisecond', todatetime(processed_time), event_time) * -1
| where latency_ms between (0 .. 300000)
| summarize avg_latency_ms = avg(latency_ms) by device_id, bin(event_time, 1m)
| sort by device_id, event_time asc
| serialize
| extend ma5 = moving_avg(avg_latency_ms, 5)

moving_avg is a common function; if it doesn't exist in the engine, implement it with prev/next or make-series + array operations.

Step 6: Export metrics to dashboard/alerting

Export the results to Power BI, Grafana or an alerting system. For alerts, create rules that trigger when avg_latency_ms or p95_latency_ms exceed thresholds. E.g.: alert when p95_latency_ms > 2000 ms and count > 50.

Verify the result

Validate by running the query and checking some conditions: 1) the averages are within expected ranges per device; 2) event_time and processed_time make sense (no negative latencies); 3) volume (count) per window is coherent. Test with synthetic events: generate events with known latencies and confirm avg_latency_ms approaches the expected value.

Conclusion

With these steps you obtain average latency per device in Real-Time Analytics, with handling of late arrivals and smoothing via moving average. Next steps: create alerts based on p95 and integrate into a dashboard. Tip: start with larger windows and reduce the window as you gain confidence in the measurements — what latency threshold do you consider critical for your application?