7-Eleven · telemetry & monitoring

Fleet observability & silent-device detection

Turning a national fleet of edge devices into something you can see: structured metrics from every site, and alarms designed around the hardest signal in IoT — silence.

CloudWatch EMF · CloudWatch Alarms · Lambda · Kinesis · Java · Node.js

Probe a stage — hover or Tab.

Fig. 1 — The dangerous failure is silence.

Problem

The most dangerous failure in an IoT fleet isn't an error — it's silence. A device that crashes loudly pages someone; a device that quietly stops reporting looks identical to a device with nothing to say.

With thousands of edge devices, per-site dashboards built by hand don't scale, and 'is the fleet healthy?' had no single answer.

Constraints

Edge devices already run at the limit of their link budget — observability can't meaningfully increase what they transmit.
Alert fatigue is the failure mode of monitoring: every alarm added must be one a human should act on.
Metrics must be queryable per site, per device type, and fleet-wide without maintaining three systems.

Architecture

Services emit CloudWatch Embedded Metric Format from the telemetry they already process — structured metrics ride the existing log pipeline, so instrumentation costs a log line, not a new agent on constrained devices.

Silent-device detection inverts the usual alarm: instead of alerting on bad values, heartbeat-expectation alarms fire on the absence of expected telemetry, scoped so one dead site link reads as one incident, not hundreds of device alarms.

Dashboards are generated from fleet metadata rather than built per site — a new site is observable the day it comes online.

Outcome

Silent failures surface as first-class incidents instead of being discovered by store staff or reconciliation gaps.
Usage-pattern baselines feed proactive maintenance alerts for dispensers and tank gauges — published as peer-reviewed work.