Alerts, digests, and channels
Two tempos, six channels, and the small disciplines that keep one event from ever becoming two reports.
The interruption and the record.
The alert is the interruption: a meaningful change, delivered as it is confirmed, classified by severity so the receiver knows whether it is a read-now or a read-today. The digest is the record: one summary of everything meaningful since the last digest, built for a morning cron and an audit folder.
The two are deliberately not the same list. Policy-facts changes whose live alerting is gated still appear in the digest, so the quiet record stays complete even when nobody was paged. What was suppressed as noise appears in neither, but remains in history.
Six ways out, one delivery discipline.
| Channel | Shape |
|---|---|
| SMTP, the audit-folder workhorse. | |
| Slack | Webhook message into the channel your team already watches. |
| Text | SMS via Twilio, for the changes that cannot wait for morning. |
| Webhook | A JSON payload to any endpoint, for your own plumbing. |
| Exec | A local command, with the target's identity passed in its environment, for the automations nobody else imagined. |
| CLI | Standard output, for a human at the terminal and for cron. |
Notify specs expand ${VAR} references from the environment, so tokens and
passwords stay in your secret store instead of in the database or the process list.
Nothing sensitive is stored or logged.
Dedup, cooldowns, and an honest ledger.
Deliveries are deduplicated per value, so a value that has already alerted does not re-alert, and rate-limited by each target's cooldown, so an unstable page cannot flood a channel. Delivery is at-least-once: a crash between a send and its record can repeat that one delivery, and the ledger records what every channel received or gave up on. Failures are the channel's problem, not the record's: what was and was not delivered is itself part of history, which is how the coverage report can state deliveries with a straight face.
That one rule earns its keep twice: a failed send is retried by that channel's next digest instead of vanishing or forcing duplicates on the healthy channels, and a change committed while a digest is being assembled lands in the next one instead of falling between two windows.