Telling Someone When Something Needs Attention
Last updated:
Automation without alerting is a liability
An automated process that runs unattended and fails silently is worse than a manual one, because at least a person notices when they have not done something.
The purpose of alerting is not to record that something failed. It is to make sure somebody who can act finds out while it still matters.
Alert on absence first
- The job did not run
- The file did not arrive
- Zero records processed where there are normally hundreds
- The queue has stopped draining
- The integration has sent nothing today
Every one of those looks like success to a system that only alerts on errors, and every one is a genuine failure.
Three tiers of urgency
| Tier | Example | Delivery |
|---|---|---|
| Interrupt | Pipeline stopped, data at risk | Direct message, immediately |
| Today | Quality drop, queue growing | Email, batched |
| Information | Weekly volumes, trends | Digest |
Most alerts belong in the middle tier and get built as the first, which is how teams learn to ignore an alert channel.
Name the next action
“Import failed” is a fact. “Import failed — check whether the supplier changed the file format, then reprocess from the quarantine folder” is an alert somebody can act on.
Putting the first steps of the runbook into the message means the person receiving it does not have to find the documentation at seven in the morning.
Prune quarterly
Any alert that has fired repeatedly without anyone acting is either wrongly tuned or unnecessary. Fix it or remove it.
Ten minutes a quarter keeps the channel meaningful, which is what makes the important alert get read.
Frequently asked questions
Where should alerts go?
How many alerts is too many?
Should alerts go out of hours?
Who should own alert configuration?
Automation running with no alerting?
The failure you have not noticed yet is the expensive one. Absence alerting is a small addition.
Related services
What we build for problems like this one