Monitoring and alerting
Which signals deserve to wake you, which belong on a dashboard, how to set thresholds that survive a busy day, and how to keep an alert channel from going numb.
Open the procedureMost automation failures are not dramatic. A run keeps executing against a stale configuration, or stops quietly while every dashboard still looks green, and nobody notices until the balances are reconciled. Monitoring exists to shorten the gap between something going wrong and someone knowing, and the useful measure of it is that gap, not the number of charts.
This section covers what to alert on and where to route it, what to record so a failure can still be explained weeks later, and the ordered first response when a key or an endpoint stops being trustworthy. The procedures that produce those events are in runbooks.
Signals worth alerting on, log lines worth keeping, and the ordered response for the moment a key or an endpoint is no longer trustworthy.
Which signals deserve to wake you, which belong on a dashboard, how to set thresholds that survive a busy day, and how to keep an alert channel from going numb.
Open the procedureA log schema that answers questions months later, the fields that make a failed transaction diagnosable, and what must never be written to a log file.
Open the procedureThe ordered response to a suspected key compromise: contain, move what can still be moved, revoke, reconstruct the timeline, then rebuild on clean keys.
Open the procedureRead alerting first, because it decides what the logs need to contain. Read the log schema second, because it decides whether an incident can be reconstructed at all. Read the incident playbook before you need it, once, calmly, and then keep it where you can open it on a phone.