Before you invest in alerting

It comes up on almost every project, usually later than it should. Before you spend anything on alerting, it is worth confirming a few things are already true.

The bill is a design document: it tells you exactly what your architecture actually does. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• An alert nobody acts on trains everyone to ignore alerts
• You have a way to tell whether it worked

What to watch for

Page on symptoms customers feel, not on every anomaly. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

Every alert should link to what to do about it. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

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
• An alert nobody acts on trains everyone to ignore alerts — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.