Notification systems that people do not switch off
A notification system is judged by what it does not send. The model that decides what is interesting is the interesting part to build and the least of what determines whether the system is used.
The failure mode is volume, and it arrives gradually
A notification system that sends too much is not obviously broken. It works on the first day, is useful for a fortnight, and by the third month everyone has filtered it into a folder or turned it off — at which point it is worse than nothing, because the signals it was built to surface are now assumed to be covered. The cause is almost never the detection logic; it is the absence of rules about repetition, about aggregation and about what counts as worth interrupting someone for.
- Recipients have stopped reading notifications or turned them off
- The same condition notifies repeatedly because nothing tracks what was already sent
- Everything is sent at the same priority, so nothing stands out
- One channel fails and the notification is lost rather than delivered another way
- Nobody can say what the system will send, or to whom, for a given event
- Recipients are notified about things they cannot act on
- Volume increases whenever a new event type is added
- A delivery failure is discovered from a person rather than from the system
The people who usually bring us this problem
A team whose alerting has been muted
The channels exist and nobody reads them, and the signals they were meant to carry are being missed.
A team building notifications into a product
Users have to be told about things and the rules for doing so need designing rather than accumulating.
A team whose notifications are unreliable
Some arrive, some do not, and there is no way to establish what happened to any particular one.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Suppression is the feature, not the refinement
Deciding not to send is most of the design. What has already been sent, what is currently open, what is being worked on, what is out of hours, what can be aggregated into one message — each rule removes volume, and volume is what makes a notification system stop being read. Without them the system degrades from useful to ignored in a predictable few months.
Delivery is a guarantee to choose, not a transport to configure
At-most-once, at-least-once or effectively-once is a decision with a cost each way: a duplicate alert versus a missed one. It has to be chosen per notification class, because a duplicate low-priority digest is harmless and a missed critical alert is not — and systems that do not decide this end up with whatever the transport happens to do.
A channel is a dependency and there are several
Email, a chat platform, SMS, a push service, a webhook. Each can be unavailable, rate-limited or slow, and a system that treats one as the path has that channel's availability as its own. Routing, fallback and what happens when every channel fails are part of the design.
Notifications about things nobody can act on are the fastest way to being muted
An alert that fires when someone cannot respond to it trains its recipients to ignore it, and the effect is not limited to that alert — it generalises to the channel. Notifying the right person is part of the design rather than a routing detail.
Capabilities
Each of these is work we carry out, not an area we advise on.
Event model and what counts as notifiable
The events the system observes, and which of them justify interrupting a person. Most events do not, and the set that does is small — establishing it is what keeps volume bounded as more events are added rather than growing with them.
Detection and enrichment
How an event is identified, what context is attached to it, and what the recipient needs in order to act without going to look something up. A notification without context produces a second step and is frequently ignored in favour of checking the dashboard directly.
Suppression and deduplication
What has already been sent, what is currently open, what is being worked on, quiet hours and aggregation windows. Each rule is stated rather than implied, and the system's behaviour for a repeated condition is a decision rather than an accident of how the code was written.
Routing and recipient selection
Who is notified for which event, including rotation, escalation and the case where nobody is. Notifying someone who cannot act is the fastest route to being muted, so the mapping from event to recipient is designed and reviewed rather than defaulted.
Delivery guarantees per class
At-most-once, at-least-once or effectively-once, chosen per notification class with the consequence stated. Critical alerts favour delivery over silence; digests favour silence over repetition. The choice is recorded so a later change does not silently reverse it.
Multi-channel routing and fallback
Which channels carry which class, and what happens when one fails — retry, route to another, or record as undelivered. A notification system whose critical path is a single provider has that provider's reliability as its own.
Escalation and acknowledgement
What happens when a notification is not acknowledged: who is told next, after how long, and what the system does if nobody responds. On a system carrying anything operational this is what turns a notification into a process.
Observability of the notification system itself
What was sent, to whom, through which channel, and what happened to it — visible without reading application logs. A system that cannot report its own delivery failures is one whose gaps are discovered by the person who did not receive something.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish what is notifiable before what is detectable
Most events are not worth interrupting a person for. The set that is, and who can act on each, is the design — and it is what keeps volume from growing every time a new event is added.
Design suppression first
Deduplication, aggregation, quiet hours, and the relationship between a new notification and one still open. These rules are the difference between a system that is read for years and one that is muted in three months, and they are designed before the first notification is sent.
Choose a delivery guarantee per class
And record it. A duplicate and a miss have different costs depending on what the notification is, and a system that does not choose ends up with whatever the transport provides — which is usually at-least-once and occasionally surprising.
Give every notification enough context to be acted on
What happened, where, since when, and what the recipient is expected to do. A notification that requires a lookup is one that is routinely ignored, and the context belongs in the message rather than behind a link.
Route to someone who can act
Including rotation and escalation, and including the case where nobody is available. Notifying the wrong person teaches them to ignore the channel, and the effect generalises to everything else it carries.
Make the system report on itself
What was sent, what failed and what was suppressed, visible without application logs. Without it a delivery gap is discovered by the person who expected a notification and did not get one, which is the worst possible detection mechanism.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Design
- The events observed, and which justify notifying someone
- Who is notified for each, and what they are expected to do
- Suppression rules: deduplication, aggregation, quiet hours, open-item relationship
- Delivery guarantee per notification class, with the consequence stated
- Channel routing, and fallback when a channel fails
- Escalation path, and what happens when nobody acknowledges
Build
- Event detection and enrichment, with enough context to act on
- Suppression and deduplication implemented as stated rules
- Routing, rotation and escalation
- Multi-channel delivery with retry and fallback
- Delivery observability: what was sent, where it went, what happened
Verification
- Suppression exercised: a repeated condition notifies once
- Channel failure exercised, with fallback confirmed
- Delivery guarantees confirmed per class, including the duplicate and miss cases
- Volume measured against what it would have been without suppression
- What the system does not cover, stated plainly
Architecture and technology
What a notification system consists of
- Events and a decision about which are notifiable
- Detection, and the context attached for the recipient
- Suppression: what has been sent, what is open, quiet hours, aggregation
- Routing: who, with rotation and escalation
- A delivery guarantee per class, chosen rather than inherited
- Channels, with fallback when one is unavailable
- Observability of the system's own delivery
Why notification systems get switched off
- Volume, which grows with each new event added
- Repetition, because nothing tracks what was already sent
- Notifications about things the recipient cannot act on
- Everything at one priority, so nothing stands out
- No context, so acting requires a lookup
- Silent delivery failures, discovered by the person who missed something
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The system underneath needs building
AI and automation engineering for systems that have to run in production.
AI engineeringThe workflow around it needs automating
Multi-step processes with the failure handling they need.
AI automationThe notifications are conversational
Where the interaction is a dialogue rather than an alert.
AI chatbotsThe notifications are operational
Failure handling and reliability for a platform.
Platform reliabilityFrequently asked
What will you use to decide what is worth notifying?
The recipient's ability to act, which is the only criterion that holds up. An event that nobody can respond to is an event that trains its recipients to ignore the channel, and the effect generalises — people who mute one alert mute the channel. So the design starts from who can do something about each event and works back to what is detected, rather than starting from everything that can be detected. The set that survives that filter is much smaller than the set of things worth recording, which is why most events are logged and few are sent.
Do you have a notification system in production?
Not one we can point at, and we would rather say so than imply otherwise — so the page claims nothing about deployments. What it describes is the engineering, which is where the substance is and which is checkable on its own terms: suppression as the primary feature, a delivery guarantee chosen per class rather than inherited from the transport, and a system that reports its own delivery failures. Those are the decisions that determine whether a notification system is still being read in a year.
Should we use at-least-once or at-most-once delivery?
Both, for different classes. A duplicate low-priority digest is harmless and a missed critical alert is not, so critical notifications favour delivery and tolerate repetition while digests favour silence and tolerate a miss. The decision is made per class and recorded, because a system that does not choose ends up with whatever the transport happens to do — usually at-least-once, which means duplicates in exactly the places nobody designed for them.
How do we stop the same alert firing repeatedly?
By tracking what has been sent and what is still open. A condition that persists is one notification with an updated state rather than a new one every interval, and the rules for that — deduplication window, aggregation, the relationship between a new notification and an unresolved one — are the design rather than a refinement applied afterwards. Repetition is the most common reason a notification system is switched off, and it is entirely preventable.
What happens when a delivery channel fails?
Whatever the routing says, which is why the routing is designed rather than defaulted. A system whose critical path is one provider has that provider's reliability as its own, so each class has a channel and a fallback, and a notification that cannot be delivered is recorded as undelivered rather than lost. The system reporting on its own delivery is what makes the difference: without it, a gap is discovered by the person who expected a notification and did not receive one.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.