Once an alert channel is ignored, every alert in it is effectively off, including the one that mattered. That is worse than building nothing, because everyone believes they are covered.
Alerting is the automation most likely to be built enthusiastically and abandoned within two months, because the failure mode is not technical. It is that people stop reading.
Once an alert channel is ignored, every alert in it is effectively off, including the one that mattered. That is worse than having built nothing, because everyone believes they are covered.
The test before building any alert
Ask one question: would somebody do something different today because of this?
If yes, it is an alert. If no, it is a report line. Most things people ask to be alerted about are report lines, and putting them in the alert channel is what destroys it.
An alert channel has a fixed attention budget. Every low-value alert spends some of it, and you cannot get it back.
How to build it
1. Start with the incidents you have already had
Not with what could theoretically go wrong. Look at the last ten things that caused a scramble, and ask for each whether an earlier signal existed. Those are your first alerts, and each one has a story that justifies it.
2. Give every alert a named owner
Not a channel, a person. An alert to a channel is a hope that somebody reads it, and in a busy week nobody does. Route to a name, and let the channel see it as a copy if you want visibility.
3. Say what to do, not just what happened
"Client X is at 90 percent of contracted hours" is a fact. "Client X is at 90 percent of contracted hours; scope conversation needed this week; owner Sarah" is an alert. The action is what converts information into a decision.
4. Set thresholds where they are still actionable
An alert at 100 percent of budget is a notification of something already happened. At 60 percent it is a choice. Every threshold should be set at the point where there is still a decision available.
5. Build escalation, not repetition
Unacknowledged after a defined window, it goes to the next person. Repeating the same alert louder trains people to ignore it faster. Escalation makes it somebody else's problem, which is what actually produces action.
6. Review and delete quarterly
Any alert that fired repeatedly with no action taken should be deleted or its threshold changed. Pruning is what keeps the channel worth reading, and nobody ever schedules it.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Native rules in the tool where the data lives | Included. | Simplest and closest to the data. Cross-system conditions are usually impossible, which is where the interesting alerts live. |
| Apps Script on a schedule | Free with Google Workspace. | Full control over thresholds, escalation timers and cross-system logic. You maintain it, and it needs its own failure alert. |
| Connector platform with filters | Per task, and polling triggers consume operations whether or not anything happened. | Quick to build. Frequent polling is expensive under this pricing model and polling is what alerting requires. |
| Monitoring and on-call tools (PagerDuty, Opsgenie) | Per user monthly, typically tens of dollars. | Real escalation ladders and acknowledgement tracking, built for exactly this. Priced and designed for engineering teams rather than small business operations. |
What it is actually worth
This is a prevention automation, so honest measurement is about response time rather than efficiency.
The measurable claim: take your last ten operational surprises. For each, estimate when the underlying signal first existed and when a human noticed. The gap is what alerting closes. If most gaps are days, this is high value; if most are hours, it is not worth much.
What I will not claim is a percentage reduction in incidents. Alerting does not prevent problems, it shortens the delay before someone acts on one, and the value of that delay is entirely specific to your business.
There is a broader caution worth borrowing from a related field. Gartner predicted in June 2025 that over 40 percent of agentic AI projects would be cancelled by end of 2027, citing inadequate risk controls and unclear value. The same pattern applies to alerting at a smaller scale: systems fail on governance and attention, not on the technology.
How it breaks
Alert fatigue, which is the default outcome. Too many alerts, too low a signal, and the channel is muted. This is not a risk to manage later; it is what happens unless you prune deliberately.
Alerts fire for conditions nobody can fix. Deeply demoralising and common. If there is no action available, it is not an alert.
The alerting system itself fails silently. The oldest problem in monitoring. Add a heartbeat: something that confirms the checker ran, so silence is distinguishable from all-clear.
Escalation reaches someone who never agreed to it. Escalation paths need consent in advance, or the escalation is just an email.
How to tell whether it worked
Mean time from condition occurring to human acknowledgement, which is the number this directly controls. Then the proportion of alerts that resulted in an action, which is your signal-to-noise ratio and should be high. If it falls below about half, prune before adding anything.