IoT platforms for infrastructure monitoring, and the questions that come first

Monitoring projects are often scoped as a platform selection: compare the options, weigh the features, choose. In our experience the platform is one of the easier parts to change later, and one of the last things worth deciding.

What is difficult to change later is the set of decisions the monitoring is supposed to support, and the arrangement of people who act when a reading is bad. Those are worth settling first.

Monitoring is a decision system, not a dashboard

A useful test for any proposed measurement: name the decision it changes, and name who makes it.

If a metric cannot be attached to a decision and an owner, it is being collected because it is collectable. That is not always wrong — some baseline data is worth having before anyone knows what to ask of it — but it should be a deliberate choice rather than the default outcome of buying a platform with a wide feature list.

A measurement nobody is accountable for acting on is a cost with a graph attached.

This framing also makes scope arguments tractable. “Do we need vibration monitoring here?” is difficult. “Whose decision changes if we know this, and what would they do differently?” usually resolves in one conversation.

The path a reading takes

Before comparing platforms it is worth agreeing on the path, because each hop is somewhere data can be lost, delayed, or silently altered.

Most platform comparisons concentrate on the middle three stages, which are also the three that vendors control and therefore the three that differ least in practice. The first and last stages — what the sensor can actually tell you, and what a person does about it — are where monitoring programmes succeed or quietly stop being used.

What to measure, and what to leave alone

Instrumenting everything is not thoroughness. Every additional measurement adds a device to maintain, a value to interpret, and a possible alert to triage.

Our starting position is to separate three categories and treat them differently:

• Condition of the asset itself. Usually the reason the project exists. Worth measuring carefully, at whatever interval the physical process actually changes on.
• Condition of the monitoring. Battery, signal quality, last-seen time, firmware. Cheap to collect and the difference between “the asset is fine” and “we have not heard anything”.
• Context that explains the other two. Temperature, weather, whether a site was being worked on. Rarely the point of the project, frequently the reason a reading looked alarming.

Deciding what counts as an alert

Alerting is where monitoring systems earn trust or lose it. A system that cries wolf gets muted, and a muted system is worse than no system, because it carries an assurance nobody is entitled to rely on.

It helps to define alerts along two axes — how confident we are, and how fast someone must act — and to accept that most conditions do not belong in the urgent quadrant.

Condition	Confidence it is real	Response expected	Route it as
Threshold crossed once	Low	None yet	Recorded, not notified
Threshold crossed and sustained	Medium	Look at it this week	Digest or queue
Rate of change outside normal	Medium	Look at it today	Named owner, working hours
Sensor silent past its window	High	Check whether it is the asset or the device	Named owner, working hours
Multiple sensors agreeing on a bad reading	High	Act now	Escalation path with a person on call

The last row is the only one that justifies waking anyone. Confidence rising with agreement between independent sensors is the most reliable signal available, and it is also the reason to avoid instrumenting a critical asset with a single device.

Retention, cost and the shape of the data

Monitoring data has an awkward cost profile: individually tiny, collectively large, and most valuable in aggregate long after the individual reading has stopped mattering.

Deciding the retention policy early is worth doing because it changes the storage design, not just a configuration value. A common approach is to keep full resolution briefly and roll up to summaries after that:

# Illustrative retention tiers. The intervals are a starting point for discussion,
# not a recommendation — the right values follow from how fast the asset changes.
tiers:
  - name: raw
    resolution: as-received
    keep_for: 30d
  - name: hourly
    resolution: 1h
    aggregates: [min, max, mean, count]
    keep_for: 24m
  - name: daily
    resolution: 24h
    aggregates: [min, max, mean]
    keep_for: indefinite

Two things are worth noticing about a scheme like this. Keeping count alongside the statistics preserves the ability to tell a quiet period from a gap in reporting. And a tier that is kept indefinitely should be small enough that “indefinitely” is a promise the operating budget can actually keep.

Failure modes worth designing for

Assume each of these will happen, because each of them will:

1. A gateway loses its uplink for a day. Do devices buffer? For how long? When the backlog arrives, is it distinguishable from a burst of live readings?
2. A sensor drifts rather than fails. Values stay plausible and become wrong. Detected only by comparison against something else, which means having something else.
3. A battery dies in the field. Predictable, so it should be predicted — low-battery reporting is part of the asset, not an optional extra.
4. A firmware update changes behaviour. Fleet-wide, all at once. Version travelling with each reading is what makes this diagnosable.
5. The person who understood the system leaves. The least technical failure mode and the most common. It is why the alert routing and the retention policy belong in a document rather than only in a platform’s configuration screen.

Where we start

We would rather instrument a small number of assets thoroughly, including the second category above, and run it through a full seasonal cycle before extending. That is not a general rule about pilots; it is specific to monitoring, where most of what you learn concerns how the measurement behaves rather than how the asset behaves.

If you are weighing this for a specific asset class, the useful conversation is about which decisions need support and who owns them. We are glad to have it in those terms.