Five mistakes teams make with alerting

Teams tend to reach for this after something has already gone wrong. These are the ones we run into repeatedly when we audit alerting.

Operability is a feature, and it has to be built rather than bought. The version that survives contact with a real deadline is the simple one.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• An alert nobody acts on trains everyone to ignore alerts
• Page on symptoms customers feel, not on every anomaly
• Never checking whether the fix actually worked

Every alert should link to what to do about it. This is the sort of thing that compounds, quietly, in both directions. Assume whoever inherits this will have half your context and none of your patience.

What to do next

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

If you want a second opinion on how yours is set up, ask.