What earns an alert
The qualifying question is about the shape of the cost curve, not the importance of the subject. Does waiting until the next scheduled review change what you can do about it? For most business facts the answer is no — revenue being down is important and it is not urgent, because the response is the same on Monday as it is today.
The things that pass are the ones with a threshold effect. A client whose drift can still be reversed by a phone call this week and cannot in six. A delivery date that will slip, where telling the client now is a conversation and telling them at the deadline is a relationship event. An automation that has silently stopped, where every day multiplies the harm. A capacity breach that will otherwise be discovered by committing to work you cannot do.
Everything else is a review item. This is the discipline the whole system rests on, and it is unpopular in the design phase because every stakeholder has something they would like to be alerted about.
There is a second qualifying test worth applying to anything that passes the first: would you want this at eleven at night. If not, it is a look-today rather than an act-now, and mixing the two severities in one channel is how the urgent ones stop being read as urgent.
The architecture, part one: the alert definition
Stage one is the definition record, and nothing fires without one. Each alert carries: the condition in precise terms, the named recipient — a person, never a channel alone — the defined action, the justification for urgency, and a severity.
Two severities are enough and three is usually too many. Act now, meaning someone does something today. Look today, meaning someone reviews it before end of day. Anything below those is a review item and does not belong in the system.
Stage two is the condition, expressed against a baseline where the signal is behavioural. Absolute thresholds work for capacity and dates; deviation from a per-entity baseline is required for anything about client behaviour, or the alert fires constantly on your most communicative accounts and never on the one that changed.
Stage three is the hysteresis rule, which is what prevents flapping. A condition that oscillates around its threshold will fire repeatedly, so an alert requires the condition to hold for a defined duration, and re-firing is suppressed for a defined window after acknowledgement.
The architecture, part two: delivery, acknowledgement and tuning
Stage four is delivery, and it pushes to where the person already is. Their chat tool, their phone, their inbox — in descending order of intrusiveness matched to severity. A dashboard is not a delivery mechanism, because it requires the act of going to look, and that act is what fails under load.
Stage five is acknowledgement. One action marks an alert as seen and being handled, which stops the re-fire and records who took it. Without acknowledgement, alerts either repeat until they are noise or fire once into a channel where four people each assume somebody else has it.
Stage six is escalation on non-acknowledgement. If an act-now alert is unacknowledged after a defined interval, it goes to a second recipient. This is the stage that makes the system trustworthy rather than hopeful, and it is almost always omitted.
Stage seven is the alert log: what fired, when, who acknowledged it, what was done. Stage eight is the monthly tuning review run against that log, asking three questions of each alert type. How often did it fire. What proportion resulted in action. Is it still justified.
The tuning rule that keeps the system alive: any alert with an action rate below about a third is retired or its threshold is moved. An alert that fires and produces nothing is training everybody to ignore the channel, and the training generalizes to the alerts that matter.
The failure edges
The first and by far the most common: too many alerts. The channel gets muted within a fortnight, and muted is worse than absent because the business now believes it is covered.
The second: alerts to a channel with no named person. Diffusion of responsibility is well documented and entirely reliable, and a shared channel with four members is the same as no owner.
The third: no defined action. A recipient who sees a condition and has to work out what to do will often do nothing, especially if they are not sure it is theirs. The action belongs in the definition, decided calmly, before it fires.
The fourth: absolute thresholds on behavioural signals. Constant noise on the accounts that behave one way, silence on the ones that changed.
The fifth: no acknowledgement or escalation. The system tells you things and has no way of knowing whether anybody heard, which means its reliability is unmeasured.
The sixth: never tuned. Alert sets decay — conditions that mattered a year ago fire on a business that has changed shape — and an untuned set becomes noise on a predictable timeline.
The seventh: alerting on a condition nobody can act on. Telling someone that revenue is behind plan produces anxiety and no behaviour, because the response is not a today-shaped action.
Where alerts come from, and the starting set
Alerts are downstream of instruments, so this system is usually built last. Each candidate alert traces back to a capture that has to exist first: client health needs contact logging, capacity needs remaining effort, delivery dates need promised dates recorded, automation heartbeats need the register. An alerting project started before those is a project to build four instruments with an alerting layer attached.
A defensible starting set is four, and it is worth resisting more. A client crossing its contact-interval threshold. A commitment that will miss its promised date, fired before the date rather than after. Committed load crossing the capacity threshold. A monitored automation running zero times in its window. Those four cover the failures that genuinely change category with delay.
Route by role rather than by seniority. The delivery date alert goes to whoever owns the engagement, not to the founder — routing everything to the founder reproduces the bottleneck in a new medium, and it is the most common way a well-built alerting system ends up making a business more founder-dependent rather than less.
What done looks like, and what it takes to build
Done is a small number of alerts a week, each of which produces an action, arriving in front of a named person who knows what to do, with a log that proves the system is being heard.
The checklist: a definition record per alert with condition, recipient, action, urgency justification and severity; baseline-relative conditions on behavioural signals; hysteresis and re-fire suppression; push delivery matched to severity; one-action acknowledgement; escalation on non-acknowledgement for the top severity; an alert log; and a monthly tuning review that retires anything under a third action rate.
The build is one to two weeks once the signals exist. It is almost always downstream of other work, because most alerts depend on capture that has to be built first — client health, capacity, delivery dates and automation heartbeats are each their own instrument.
The prerequisite worth stating: a willingness to decide the action in advance. That is the uncomfortable part, because it commits you, and it is far more pleasant to have the information and keep the option. A business that will not decide the actions will build the alerts and then accumulate them unread.
An alert needs a named person, a defined action, and a reason it cannot wait for the weekly review. Retire anything with an action rate under a third, or the channel gets muted.