Latest · Tested · Published 11 Sep 2026 · GA Applications editorial
An alert nobody acts on is worse than no alert.
Remote monitoring earns its keep when every alert passes three tests: someone can act on it, missing it has a real consequence, and false alarms are rare enough that people keep listening. Confidence in the sensor, the threshold that triggers, the owner who responds and the fallback when comms fail must be designed together — an alert is a promise, and broken promises teach people to ignore the next one.
Test format used in GA monitoring scoping. Example rows are illustrative, not measurements of any site.
Recognition
Monitoring versus telemetry
A sensor that reports is telemetry. Monitoring exists only when a reading can change an action. The gap between the two is where monitoring projects quietly die: twenty alerts a day, each individually ignorable, until the one that mattered arrives and is ignored with the rest.
The mechanism is well understood in any control room: every false alarm spends a little of the listener’s trust, and trust, once spent, applies retroactively — past alerts get re-read as noise too. GA treats that mechanism as practitioner inference rather than citing a study, and it is labelled accordingly below. What is not inference is the design consequence: the alert list is a budget, and every row must justify its spend.
The fix is not fewer sensors. It is designed alerts: each one carrying its confidence, its threshold, its owner and its fallback into the same conversation.
Actionability, consequence, false-alarm burden
The alert value test
Run every proposed or existing alert through three columns. Anything failing two of them gets redesigned or removed.
| Alert | Actionable? | Consequence if missed | False-alarm burden | Verdict |
|---|---|---|---|---|
| Tank below reserve level | Yes: order water or switch source | Stock or household without water | Low, with a validated sensor | Keep — the model alert |
| Pump run-time abnormal | Yes: inspect before failure | Burnout, replacement cost, downtime | Medium: needs tuned thresholds | Keep after tuning |
| Battery voltage drifting down | Yes: schedule a site visit | Silent monitoring death | Low | Keep |
| Tank temperature moved 0.5° | No practical action | Usually none | High: normal weather noise | Remove, or log silently |
| Hourly “system online” heartbeat | No action attached | None — absence is the signal | Total: trains people to ignore | Remove; alert on silence instead |
| Comms lost for six hours | Yes: check the unit, not the tank | Blind period goes unrecorded | Low, with a sane timeout | Keep |
Rows are illustrative examples, not measurements of any particular site. Run the test on your own alert list; the verdicts follow from your consequences, not from this table.
Designed together
The four design questions
- Confidence. Does the sensor tell the truth here — placement, calibration, fouling, power? A reading nobody trusts produces alerts nobody acts on.
- Threshold. At what value does a reading become a decision, and who set that number from what evidence? A round number from a brochure is not a threshold.
- Owner. Whose phone receives it, what do they do next, and what happens when they are unavailable? An alert without an escalation path has no owner; it has an audience.
- Fallback. What happens when comms fail, power fails, or the sensor lies — a safe state, a local alarm, a manual check cadence?
Designed separately, these produce an alarm system that cries wolf. Designed together, they produce the calm kind: one that pages someone twice a year and is believed when it does. This is the shape of GA’s water tank automation and connected equipment work — states and failure modes first, sensors last.
Ninety minutes per alert
Designing one alert properly
The discipline is cheap. The undisciplined version costs a monitoring system.
Write the decision
“When X reads Y for Z minutes, [name] does [action] within [time].” If that sentence cannot be written, the alert cannot be designed.
Set the threshold from evidence
Operating records, failure history, margins. Log the basis next to the number, so the next person can argue with it.
Test the false-alarm rate silently
Run two weeks without paging anyone: log what would have fired, count the false positives, tune before any phone is involved.
Rehearse the response
Fire one test alert end to end, including the fallback path. An unrehearsed alert is a hypothesis, not a control.
Where GA’s work stops
Safety-significant monitoring — electrical protection, pressure systems, anything whose failure risks people — is designed up to a documented boundary, then handed to qualified people. Remote visibility supports judgement; it does not replace certification, and GA does not imply certification it does not hold. If your alert list includes anything safety-significant, say so at the start of the conversation.
Evidence honesty
Sources, method and what would change this
- Demonstration data
Alert value test format
The three-column test reflects the format GA uses when scoping water and equipment monitoring. The example rows are illustrative, not site data.
GA Applications field practice
- Inference
Alarm fatigue mechanism
The claim that false-alarm burden teaches people to ignore later alerts is GA practitioner inference; no NZ-specific frequency data is claimed.
GA Applications editorial
- Demonstration data
Four design questions
Confidence, threshold, owner and fallback are the headings under which GA scopes monitoring engagements.
GA Applications method documentation
- Proposal
What would change this conclusion
If silent-then-tuned deployments in GA’s work produced worse outcomes than immediate alerting, the method order would be revised and the change dated here.
GA Applications editorial
Start with the alert you already ignore
Describe the equipment, the water, or the alert that fires too often. GA scopes monitoring from operating states and failure modes — sensors last, not first.
The deliverable is a designed alert list, not a box of hardware.