The failure mode of a mature automation system is not silence. It is a stream of notifications you have trained yourself to swipe away from the lock screen without reading, and one of them, eventually, was the one that mattered.
A notification is a small tax on someone's attention. Charge it too often and they stop paying; the phone goes on silent and the one alert that mattered joins the pile. Everything on this page is about keeping the tax low enough that people keep paying it a year later.
Pick thresholds from your own data
A threshold chosen by feeling is either too tight (you mute it) or too loose (it never fires). Both are useless, and you cannot tell which you have without measuring.
Before setting a limit, pull the actual distribution out of your history. How long do the gaps between events really run? What is the tail? Then choose a value past the tail you are willing to be woken for, and write the measurement into the comment so the next person, probably you, knows it was derived rather than guessed.
Three cheap controls that fix most noise
- Duration. Require the condition to hold for a while before speaking. Kills threshold flapping outright, and costs you only the reaction time you did not need.
- Quiet hours. Ask what the recipient can actually do at 3 a.m. besides resent you. For a leak, plenty. For tomorrow's air quality, nothing, so it can wait until morning.
- Cooldown. One message per situation, not one per evaluation. Especially important once you add periodic level checks, which will otherwise re-fire happily forever.
Applied to the pollen example, those three turned three notifications, two nocturnal, into one, in the morning, on the same underlying data.
Advice needs to know where you are
This system watches two dwellings in two countries. The ventilation advisor compared indoor and outdoor dew points, decided a cross-breeze would help, and told me to open the windows. The physics was right. The windows were five hundred kilometres away.
A notification that informs can travel anywhere. A notification that instructs a physical action is only useful if the hands it addresses are in the same building as the handle, so it must be gated on presence, in this case on which city's zone the phone is in. The quiet-hours question above generalises: not just "what can the recipient do at 3 a.m." but "what can the recipient do from here".
Let the repair outrun the page
If something self-heals, alerting before the repair has had a chance to run is pure noise. Work out the worst-case recovery time and set the alert threshold beyond it. Then the only things that reach you are faults the automatic recovery could not fix, which is exactly the set you can do something about.
Escalate by consequence, not by loudness
Not every alert deserves the same channel. A useful hierarchy:
| Kind | Route |
|---|---|
| Informational, you would like to know eventually | Normal push, quiet hours apply |
| Actionable, do something today | Normal push, no quiet hours |
| Safety or property, minutes matter | Push plus a second, independent channel |
Make silence legible
The final and least obvious piece. When an alert does not arrive, you cannot tell whether nothing happened or the alerting broke. Two habits fix that:
- Log arrivals, not just actions. If an inbound webhook is rejected (bad credential, malformed body) record that it arrived. Otherwise "nothing was sent" and "something was sent and silently dropped" look identical, and you will spend an evening learning which.
- Send a periodic proof of life so absence becomes measurable. See the dead-man's switch.
The best alert in this house is the one that has never fired. The second best is the one that fired once, was right, and then had the decency to stop.