Why I Still Route Some Alerts Through Email

We have Slack bots, webhook everything, and a dashboard nobody opens. Yet email is still the protocol that:

• Non-dev stakeholders actually check
• Survives “we turned off notifications for that channel”
• Archives itself in a thread nobody has to grep

Example: weekly digest from n8n

Workflow sketch:

1. Cron Monday 8 a.m.
2. HTTP to internal metrics JSON
3. Function node formats a short HTML summary
4. Send email (SMTP or provider node) to a mailing list

Not clever. Reliable.

When email is the wrong tool

• Real-time paging (use the proper on-call tool)
• Secrets in subject lines (never)
• Anything needing a button click to acknowledge legally — use a system built for that

Sample HTML snippet I reuse

<h2>Weekly summary</h2>
<ul>
  <li>Failed jobs: {{ $json.failed }}</li>
  <li>Queue depth: {{ $json.depth }}</li>
</ul>

Variables depend on your n8n expression syntax — point is keep the template dumb.

Plain text fallback

Some clients mangle HTML. I send multipart mail when the provider allows: text/plain first with the same facts, HTML as the pretty layer. The CEO’s phone mail app from 2014 still exists in the wild.

Unsubscribe and lists

Internal digests shouldn’t need CAN-SPAM footers, but labeling the list (“infra-weekly@…”) and having an owner matters. When the person who owned the cron leaves, someone should know which workflow to disable — otherwise you spam ex-employees forever.

Rate limits and retries

SMTP providers throttle. I backoff retries in the workflow and log failures to Slack once, not fifty times for the same stuck send. Learned that after a provider soft-banned a dev key.

---

Email isn’t sexy. Delivered beats sexy when finance asks “did we know about this spike?”