How do you calculate telemetry event delivery rate?

Divide events delivered by events expected and multiply by 100. With 148,000 delivered against 150,000 expected, that is 148,000 ÷ 150,000 × 100 = 98.67%.

What is a good telemetry delivery rate?

Most IIoT SLAs target 99.5% or higher for critical telemetry. At 98.67% you are 0.83 points below a 99.5% target, small in percent but it represents 2,000 missing events that could include alarms.

How do I know the 'expected' event count?

Derive it from device count, sampling rate, and period, e.g., 100 devices at one event per second over the window. A wrong expected count makes the rate meaningless, so validate it against device configuration.

Does a high delivery rate mean the data is good?

No. Delivery rate only counts whether events arrived, not whether they arrived on time, in order, or with valid values. A device can deliver 100% of events that are all stale or wrong.

What causes telemetry events to go missing?

Gateway outages, network saturation, buffer overflows, MQTT/QoS misconfiguration, or devices going offline. A 2,000-event gap usually points to one device or gateway dropping, not a uniform network issue.

Is delivery rate the same as uptime?

No. Uptime measures whether a device or gateway is reachable; delivery rate measures whether the expected messages actually arrived. A device can be 'up' but still drop a fraction of its events under load.

IIoT, SCADA & Edge Connectivity calculator

Telemetry Event Rate Calculator

Telemetry event delivery rate measures how reliably your edge devices and gateways actually land their expected messages, sensor readings, alarms, heartbeats, into the platform over a period. SCADA, IIoT, and data-engineering teams use it as the core data-reliability KPI, because every analytics model, dashboard, and predictive alert is only as trustworthy as the telemetry feeding it. It matters because missing events are silent: a 1.3% delivery shortfall can hide a dropped gateway, a saturated network, or a misconfigured buffer that quietly corrupts trends. Tracking actual versus expected against an SLA target turns 'the data looks fine' into a number you can alarm on.

What this calculator does

Estimate telemetry event delivery rate from events delivered to the broker or historian against events expected for the period, against a delivery target.
Use it when an OT data ops or analytics lead is verifying that telemetry events (machine cycle, batch step, alarm) are landing at expected volume before signing off on a model rebuild or cutover.
It computes the percentage of expected telemetry events that were actually delivered and the point gap between that rate and your delivery target.

Formula used

Telemetry event delivery rate = events delivered ÷ events expected × 100
Delivery gap to target = target rate - actual rate (negative gap means below target)

Inputs explained

Telemetry events delivered in the period:
Telemetry events expected in the period:
Telemetry delivery target:

How to use the result

Use it when monitoring data-pipeline health, reporting against a telemetry SLA, or diagnosing suspected gaps in edge-to-cloud delivery.
It measures volume, not correctness or timeliness, events can arrive late, out of order, or with bad values and still count as delivered, so pair it with latency and data-quality checks.

Current U.S. benchmarks

Global copper trades at $13,543 per tonne (IMF via FRED, Jul 2026), up 38.6% in a year, and U.S. industrial electricity averages 8.71 cents per kWh. Both feed electrified-hardware unit economics.

Common questions

How do you calculate telemetry event delivery rate? Divide events delivered by events expected and multiply by 100. With 148,000 delivered against 150,000 expected, that is 148,000 ÷ 150,000 × 100 = 98.67%.
What is a good telemetry delivery rate? Most IIoT SLAs target 99.5% or higher for critical telemetry. At 98.67% you are 0.83 points below a 99.5% target, small in percent but it represents 2,000 missing events that could include alarms.
How do I know the 'expected' event count? Derive it from device count, sampling rate, and period, e.g., 100 devices at one event per second over the window. A wrong expected count makes the rate meaningless, so validate it against device configuration.
Does a high delivery rate mean the data is good? No. Delivery rate only counts whether events arrived, not whether they arrived on time, in order, or with valid values. A device can deliver 100% of events that are all stale or wrong.
What causes telemetry events to go missing? Gateway outages, network saturation, buffer overflows, MQTT/QoS misconfiguration, or devices going offline. A 2,000-event gap usually points to one device or gateway dropping, not a uniform network issue.

Last reviewed 2026-07-13.