Home / Case studies / Utility (anonymised)

From telemetry “firehose” to operable water network operations

Anonymised · multi-site · time-series and dashboards

Problem

A regional operator’s telemetry stack could tell that something was happening, not what a shift lead should do next. Data volumes grew; alarm fatigue was real. Time-series storage on cloud was in play; naming and ownership between field and control room were weak.

Context and constraints

Uptime expectations, a mixed vendor history, and limited patience for a multi-year “platform” programme. Cloud spend had to be defensible, not a science project. Stack and identifiers are deliberately omitted.

Approach

Tighten signal-to-noise: which metrics mattered for daily ops vs engineering forensics. A thin reference path for ingestion and retention (including time-series data on AWS) with explicit RPO/RTO and cost guardrails, then a dashboard language operations could trust. Where a multi-tenant or multi-site IoT platform was in play, align rule design and alarms with the same identifiers field teams and field service systems could use, so a spike on the network did not get “lost in translation” between SCADA, cloud, and a work order.

From many signals to one defensible next step ingest + edge Triage, naming, ownership Time-series, rules, alerts, RBAC Shift + FS / support
Conceptual: raw telemetry → clarity → platform views → the teams that act

Architecture and stack (high level)

MQTT / edge ingest · cloud time-series and alerting · role-based views · audit-friendly exports.

Outcome

Operations stopped treating the monitoring stack as a wall of red; fewer after-hours “unknown” calls. A scoped roadmap for the next 12–24 months, not a shelf PDF.

Related services

IoT & telemetry · AWS architecture · Discuss a similar case

Book a scoping call