Alerting: the questions we get asked most

Every audit we run turns up some version of this. The questions about alerting that come up most often on our calls.

Operability is a feature, and it has to be built rather than bought. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Do we need to care about this?

An alert nobody acts on trains everyone to ignore alerts. It is worth being explicit about, because assumptions differ quietly. If two people in the business would answer this differently, that gap is the actual problem.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Every alert should link to what to do about it. Small and consistent beats large and occasional here. It rarely shows up as a line item, which is exactly why it slips.

In practice

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about alerting before you move on:

• Someone can say what the current setup is without going to look
• Every alert should link to what to do about it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.