Designing alerts people do not ignore: how to avoid alert fatigue

Alert fatigue is what happens when a system sends so many warnings that people stop paying attention, and then miss the one that matters. It is common with IoT monitoring: a temperature sensor that messages every few minutes, a group chat flooded with "device offline" notices, an alarm everyone has learned to silence. The fix is not fewer sensors but better alert design: alert only when a person needs to act, make each message clear, send it to the right person, and escalate when no one responds.

Signs your alerts are not working

• Staff have muted the WhatsApp group or the app.
• People say "it always does that" when an alert arrives.
• The same alert fires and clears many times a day.
• No one can say who is supposed to respond at night.
• After a real problem, you find that the alert was sent but no one acted.

Principles of an alert people trust

Alert on action, not on information

Ask of each alert: what should the person do when they get it? If the answer is "nothing, just be aware", it belongs on a dashboard or in a daily summary, not in an alert. The IoT dashboards article covers what belongs on a screen instead.

Wait before you shout

A door opened for a moment, or a reading that spikes once, is usually not a problem. Good alerts require a condition to last for a set time before firing, and to clear properly before firing again. This single change removes much of the noise. The right waiting time depends on the risk: a cold room can tolerate a door opened briefly, but a gas reading cannot be left to wait.

Use levels

Not everything is urgent. Separate warnings from emergencies, and send them through different channels.

One problem, one alert

If the power goes out, you do not need a separate alert from every sensor in the building. Group related alerts into one message that names the likely cause.

Send it to someone who can act, with a backup

An alert to "everyone" is often an alert to no one. Name a person for each alert type and time of day. If they do not acknowledge it within a set time, escalate to the next person on the list.

Alert when the system itself goes quiet

A device that dies sends no alerts at all, which looks exactly like "everything is fine". A "no data received" alert protects against this.

Alert levels: an example

The limits behind each level should come from the product's storage instructions, the equipment manufacturer or a qualified technician, not from guesswork. For safety risks such as gas and smoke, alerts are an extra layer beside proper detectors and alarms, never a replacement for them.

Writing the message

Compare two alerts:

• Weak: "ALERT: Sensor 4 value out of range."
• Better: "Cold room 2 (Bogura depot) has been above its set limit since 2:10 am. Check the door and the compressor. Reply OK to acknowledge."

A good message says where, what, since when, and what to do first. Write it in the language the reader uses; for many staff in Bangladesh, that means Bangla.

Test and review

• Send a test alert during setup and confirm that each person receives it, including at night.
• Review alerts every month: which fired most, which were ignored, and which were false.
• Retire or adjust alerts that no one acts on.
• After any real incident, check whether the alert arrived in time and reached the right person.

A short checklist

1. Every alert has an action and an owner.
2. A condition must persist before an alert fires.
3. There are at least two levels, sent through different channels.
4. Unacknowledged critical alerts escalate.
5. Silent devices trigger a "no data" alert.
6. Messages say where, what and what to do.
7. Alerts are reviewed regularly.

For examples in practice, see cold storage temperature alerts and server room monitoring. The IoT development service page explains how I set up alerts on monitoring projects.