diff --git a/05-troubleshooting/security/freshclam-logwatch-false-no-updates.md b/05-troubleshooting/security/freshclam-logwatch-false-no-updates.md
index 86fb4f0..2d3629f 100644
--- a/05-troubleshooting/security/freshclam-logwatch-false-no-updates.md
+++ b/05-troubleshooting/security/freshclam-logwatch-false-no-updates.md
@@ -63,6 +63,17 @@ Deploy the drop-in wherever freshclam runs in daemon mode. On the fleet it's a t
 
 - **Confirm freshness before suppressing.** If signatures really are stale (freshclam off / no update timer), suppressing hides a genuine security gap. On a daemonless host that disabled freshclam, the warning is *true*.
 - The script's built-in options B/C (about syslog format) don't apply when freshclam logs to its own file (`LogSyslog false`); `$ignore_no_updates` is the right lever.
+- **Don't alert with `mail`.** The `mail`/`mailx` CLI is absent on most fleet hosts (only Postfix's `/usr/sbin/sendmail` is guaranteed). A health script that ends in `mail -s … root` silently fails to send. Pipe a headered message to `/usr/sbin/sendmail -t` addressed to `admin_email` directly (don't rely on an `/etc/aliases` `root` rewrite either).
+
+## Proactive monitoring (don't rely on logwatch for "is it updating?")
+
+Since logwatch's heuristic is suppressed, a **direct daily watchdog** is what actually catches a dead freshclam. `configure_clamav.yml` deploys `/etc/cron.daily/clamav-freshness` (MajorAnsible `9d1a1a9`) to every `clamav`-group host: it emails the admin (via `sendmail`) if `clamav-freshclam` is inactive **or** `daily.cld` is older than `clamav_staleness_threshold_days` (default 3) — and stays silent otherwise. Test without emailing:
+
+```bash
+CLAMAV_STALE_DAYS=0 /etc/cron.daily/clamav-freshness   # forces the stale branch
+```
+
+This is what would have caught dcaprod's 20-day drift immediately instead of it surfacing by accident.
 
 ## Related