When alerting is worth the effort

The gap between knowing this and actually doing it is where most teams lose ground. Alerting is not free, and pretending otherwise leads to bad decisions.

The bill is a design document: it tells you exactly what your architecture actually does. It rarely shows up as a line item, which is exactly why it slips.

When it is worth it

An alert nobody acts on trains everyone to ignore alerts. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. The reasoning matters more than the rule, because the rule has exceptions.

How to decide

Every alert should link to what to do about it. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

In practice

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about alerting before you move on:

• Someone can say what the current setup is without going to look
• Page on symptoms customers feel, not on every anomaly — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.