Remote monitoring your team still trusts in month six
Streaming sensor data is the easy part. Everything hard happens after the first false alarm, when people start deciding whether to believe the system.
Remote monitoring projects rarely fail on the hardware. They fail on trust. Two weeks of alerts that turned out to be nothing teaches your team to swipe the notification away. After that the platform runs perfectly and nobody reads it.
What this class of system demands
4 things that decide this
- 01Thresholds belong to the site, not the fleet. A tank in full sun moves differently from one in a shed, and a single global number guarantees noise somewhere.
- 02Tell a broken sensor apart from a real event. They need different people, different urgency, and mixing them is what trains staff to ignore both.
- 03An alert has to become assigned work. TankAware turns a flagged deficiency into a vendor work order with an owner, which is the half a notification cannot do.
- 04Measure response, not delivery. If nobody acted on an alert, that is a design defect to fix rather than a statistic to report.
- SenseReadings arrive, some wrong.
- CleanFault or event? Decide first.
- CompareAgainst this site's normal.
- AlertTo someone who can act.
- AssignA work order with an owner.
- CloseSigned off, in the audit trail.
Most platforms stop at step four and call it monitoring. The value is in steps five and six.
The four problems every build hits
These appear whether you are watching tanks, machines or vehicles.
Normal is local
Every site has its own daily rhythm from temperature, delivery patterns and usage. Model that per site before setting any threshold, or you will alert on the weather.
Sensors lie slowly
Drift is more dangerous than failure. A dead sensor is obvious; one reading two percent low for months quietly corrupts the baseline everything else is judged against.
Connectivity is not guaranteed
Remote sites drop out. Buffer readings at the edge and reconcile on reconnect, or your history has holes exactly where the interesting event happened.
Nobody watches a dashboard
Screens get opened when something is already wrong. The system has to reach out on a channel people answer, and it has to be right often enough to keep that permission.
Tuning is the project, not the launch task
Teams budget for the build and treat threshold tuning as configuration. It is the opposite. You cannot know a site's normal range until you have watched it through a season.
So the months after launch matter more than the weeks before it. We stayed on TankAware's predictive models as new sites came online, because a model tuned on ten sites is not tuned for the eleventh.
- Watch a full seasonal cycle before you trust a threshold.
- Track how often each alert type was acted on, and retire the ones that never are.
- Re-tune when a site changes use. New tenants and new patterns break old baselines.
Systems running unattended across sites
A telemetry dashboard against a monitoring system
Both show you the readings. Only one of them changes an outcome.
| Criterion | Dashboard only | What production requires |
|---|---|---|
| Thresholds | One global number for every site. | Modelled against each site's own normal. |
| Bad readings | Treated as real events. | Sensor faults separated and routed differently. |
| Lost connection | A gap in the chart. | Buffered at the edge, reconciled on reconnect. |
| After the alert | Someone has to remember. | A work order with an owner and a close-out. |
| Six months in | Alerts muted, dashboard unopened. | Response rate tracked, noisy rules retired. |
The stack this work runs on
Data and models
Platform
Controls
“TankAware has revolutionized how we manage petroleum sites. The real-time data and automation have exceeded expectations.”
Blake Sutherland · President, Sutherland Excavating Ltd.
What operators ask us
01How do you stop false alarms training staff to ignore alerts?
Model each site's normal daily swing first, then set thresholds against that instead of one global number. Separate sensor faults from real events so they reach different people. Then track response rates and retire any alert type nobody acts on.
02What happens when a remote site loses connectivity?
Readings buffer at the edge and reconcile when the link returns, so the history has no hole where the interesting event happened. Designing for reconnection late usually means rebuilding the ingestion path.
03Is predictive maintenance real or marketing?
Real, and narrower than the word suggests. What works is flagging a deviation from a site's established pattern early enough to act. What does not work is promising to predict a specific failure date from a handful of months of data.
04Do you supply the sensors?
We integrate with what is on your sites rather than manufacturing hardware. The scoping question is what your existing devices expose and how often, since older equipment sometimes needs a gateway in between.
05How many sites can one platform hold?
TankAware was built multi-tenant from the start, with each client organisation isolated under its own subdomain and five permission tiers. Designing for one site and scaling later is the migration nobody enjoys, so that decision belongs at the beginning.
