# An alert nobody reacts to is worse than no alert

> A channel with two hundred messages a month and not one action trains the team to ignore messages. That training then works during a real incident too.

Source: https://naasson.com/en/blog/an-ignored-alert-is-worse-than-none/
Published: 2026-04-22
Language: en
Direction: Cloud by Naasson (https://naasson.com/en/cloud/)
Publisher: Naasson — https://naasson.com

---
Most projects that have monitoring also have an alert channel nobody reads. The usual explanation is lack of time. The real cause is different: the channel taught people not to read it.

The mechanism is simple. An alert fires, someone looks, and it turns out nothing needs doing. This repeats twenty times. On the twenty-first, nobody looks, and that is rational behaviour, because in the previous twenty cases there was no reason to look.

The problem is that the twenty-second alert may be real.

## The only criterion for an alert

Is there an action a person must take now.

If there is no action, it is not an alert but a metric. It belongs on a dashboard people look at when they have a question, not in a channel that interrupts work.

This criterion cuts away most of what is usually configured. CPU load went up: what is the action? None, until users are affected. The disk is seventy percent full: what is the action? None; it is a reason to plan, not a reason to interrupt.

## What remains

Alerts that users are already having a bad time, or will within a known period.

The error budget is burning faster than planned. The share of failed requests on a route has gone up. The disk will be full in a day at the current rate: here there is an action, and the deadline is clear.

Notice that every one of these has either someone affected or a deadline. That is what separates an alert from a metric.

## Why this is tied to your own stack

Because configuring by this criterion requires freedom in choosing what to fire on.

In a commercial dashboard, the set of possible conditions is defined by the product. It usually covers technical metrics, because they are universal, and those are exactly the ones that fit the action criterion poorly.

A condition like "the error budget for a service level objective is burning faster than planned" is expressed on your own data, with percentiles and your own history. It is not exotic, it is standard practice, but it requires the data and the rules to be yours.

## What to do with an already cluttered channel

Do not clean it up gradually. Gradual cleanup does not work: each individual alert seems "useful in principle".

The reverse approach works: turn them all off and turn them back on one at a time, each time answering the question about the action. The list after this procedure is usually several times shorter than the original, and the first real incident shows that nothing important was lost.

## The side effect of a short list

There are few alerts, and people start reacting to them. Then it becomes possible to require a reaction, that is, to agree that a firing means someone has looked.

With a long list, that agreement cannot be reached, however many procedures are written. People cannot react to two hundred messages a month, and they will not.