Section Alerting

Alerting, on-call and noise

An alert is a request for a human. Most systems make far more of them than they can justify.

Teams applying this principle can also compare practical guidance on employee time tracking app, keeping time and activity records separate from the judgement they are meant to inform.

7published
7planned
0scores out of ten
0tools we claim to have tested

This section is about the part of monitoring that reaches a person. A dashboard waits to be looked at. An alert arrives, and arriving is the whole of what distinguishes it.

The articles cover what an alert has to justify before it is allowed to interrupt anyone, why thresholds set once decay into noise, what alert fatigue actually is and how to measure it, how escalation should be arranged and who decides, what an alert should carry with it, the maintenance of deleting alerts nobody schedules, and how to review an incident without turning it into an inquiry about a person.

The connection to the first section is direct. An alert is a proxy with a consequence attached, and the consequence is somebody's night. Everything the measurement section says about distance from the thing, base rates and the cost of a threshold applies here with a person on the receiving end.

Nothing in this section names a product. The selections do that, once the class of problem is settled.

Published

Further context

For a primary, standards or institutional reference, see RFC 5424 on syslog.

Start from the class of problem, not the list of tools

Every selection here names the situation first and the criteria second. Product names come last, and each one carries the line describing what it costs you.