Email Notifications

You are on call. Your phone buzzes with a PagerDuty push notification for a SEV1. You open the incident, start debugging, and 40 minutes later you realize the context you need is in an email that arrived 3 minutes before the phone page. The email has the Datadog graph snapshot, the runbook link, and the exact error string. The push notification had a one-line summary.

Email is the oldest alerting channel in operations. It is also the most misunderstood. Most teams either over-rely on it (treating it as a pager) or dismiss it entirely (sending everything to Slack). Both approaches fail.

Atlassian Opsgenie ranks email as the fourth choice for paging, behind phone, SMS, and push. But email is the only channel that can carry a 200-line incident context block with embedded graphs, runbook links, and thread history. PagerDuty, Datadog, and Grafana all default to email as the rich context delivery mechanism, not the wake-up mechanism.

The real question is not whether to use email. It is how to use email so that the right context reaches the right person without burying real signals in noise.

Every incident response system uses a multi-channel strategy. Each channel serves a different purpose.

Email sits at the bottom of the urgency stack and the top of the context stack. A phone call tells you something is broken. An email tells you what is broken, why, and what to do about it.

Amazon SES, the sender behind most alerting platforms, processes email at roughly $0.10 per thousand messages. Delivery p95 is 2 to 5 seconds when sender IPs are warm. But delivery time and inbox arrival time are different things. Gmail rate-limits inbound messages to 3,600 per hour per unverified domain. Office 365 is similarly aggressive. Without SPF, DKIM, and DMARC configured correctly, your alert emails land in spam.

The pattern that works in production: use email for rich context delivery, digest summaries, postmortem invitations, and compliance audit logs. Never use email alone as a pager.