How to calculate throughput per service in Real-Time Analytics

João Barros 16 de October de 2026 4 min read

We will calculate throughput (events per second) per service in Real-Time Analytics to monitor capacity and detect spikes. This example shows how to aggregate events in fixed time windows and normalize per second, useful for dashboards and scalability alerts.

Prerequisites

Account with access to a Real-Time Analytics instance (e.g., Azure Data Explorer/Kusto or a compatible service).
Event source with a timestamp and a service_name field (e.g., telemetry, logs, or API events).
Basic knowledge of KQL/querying and access to the events table.

Step 1: Understand the goal and data format

We want one metric: events per second per service over time. The data must have at least a timestamp (e.g., timestamp, EventTime) and a service identifier (service_name). Check the timestamp format and timezone to avoid incorrect values.

Step 2: Count events per fixed window (example 1 second)

We use 1-second windows to obtain throughput per second. In many systems, using very small windows can generate noise; choose 1s, 5s or 10s as needed. Below is an example in KQL that aggregates by 1s window and by service_name.

EventsTable
| where EventTime >= ago(10m)
| summarize events_count = count() by bin(EventTime, 1s), service_name
| order by EventTime asc

Step 3: Normalize to get events per second when the window is larger

If you prefer 10s windows to smooth variation, divide the count by the window duration to get events/second. This avoids false spikes and makes comparisons more stable.

let window = 10s;
EventsTable
| where EventTime >= ago(30m)
| summarize events_count = count() by bin(EventTime, window), service_name
| extend events_per_second = todouble(events_count) / todouble(tolong(window) / 1s)
| order by EventTime asc

Step 4: Handle periods with no events (fill zeros)

If a service produces no events in a window, you want to see 0 instead of a missing row. Use make-series or join with a time series. make-series automatically fills with 0 when using count().

EventsTable
| where EventTime >= ago(30m)
| make-series events_count = count() on EventTime from ago(30m) to now() step 10s by service_name
| mv-expand EventTime to typeof(datetime), events_count to typeof(long)
| extend events_per_second = todouble(events_count) / 10.0
| order by EventTime asc

Step 5: Aggregate for multiple granularities (e.g., 1s, 1m) and prepare for visualization

It is useful to have multiple granularities for dashboards. Create a query that generates both and choose in the client (Power BI, Grafana). Here we show how to produce 1s and 1m using two queries and union.

// 1 second
let a = EventsTable
| where EventTime >= ago(15m)
| summarize events_count = count() by bin(EventTime, 1s), service_name
| extend granularity = '1s', events_per_second = todouble(events_count);

// 1 minute
let b = EventsTable
| where EventTime >= ago(15m)
| summarize events_count = count() by bin(EventTime, 1m), service_name
| extend granularity = '1m', events_per_second = todouble(events_count) / 60.0;

a union b
| order by EventTime asc, service_name

Step 6: Avoid spikes from bursts and outliers (smoothing and percentiles)

Short spikes can bias metrics. For dashboards use a moving average or percentiles. Example of a simple moving average in KQL with series_fir()

// example of simple moving average (window 5 points)
EventsTable
| where EventTime >= ago(30m)
| make-series count() on EventTime from ago(30m) to now() step 10s by service_name
| extend smoothed = series_fir(events_count, dynamic([0.2,0.2,0.2,0.2,0.2]))
| mv-expand EventTime to typeof(datetime), events_count to typeof(long), smoothed to typeof(double)
| extend events_per_second_smoothed = smoothed / 10.0

Verify the result

Confirm that each service_name has continuous time (or zeros) and that events_per_second has plausible values. Check extremes: the sum of events_per_second per window should approximate the total count() per window. Test with known data: generate test events at N per second and compare with the output.

Conclusion

You now have a practical way to calculate throughput per service in Real-Time Analytics, with options for windows, zero-filling and smoothing. Next steps: connect to a dashboard (Power BI/Grafana) and create alerts when events_per_second exceeds thresholds. Tip: try different windows and compare results to choose the one that best reflects your service's reality.