Nobody watches a dashboard at 3am. Alerting is the product.
Deliverability incidents are cheap to fix in the first hour and expensive to fix in the second week. Here's the alerting model BigStats ships — thresholds, per-domain anomalies, escalation, Slack and webhooks, and a daily digest — and why MailOps teams need all five.
Every deliverability incident has the same shape. Something changes — a list segment, a template, a warming IP, a provider's policy — and for a while the numbers stay inside the range where nobody notices. Then the filter learns, the bounce curve steepens, and by the time somebody opens a report the damage is measured in weeks of reputation rather than hours of sending.
The fix is not a better dashboard. A dashboard requires a human to be looking at the right report, at the right grain, at the right moment. Alerting inverts that: the system watches continuously and interrupts you only when the numbers say it is worth interrupting. That is the whole design brief, and it is why we have just shipped a substantially deeper alerting layer in BigStats.
Five things alerting has to get right
- Detect on the metrics that actually move first — deferrals and per-provider bounces lead, complaints and delivery rate confirm.
- Detect at the grain where the problem lives, which is almost never the workspace average.
- Reach the human who is on duty, on the channel they actually watch.
- Keep chasing until somebody owns it, and stop chasing the second they do.
- Give the team a way to see everything still open without reading their inbox backwards.
1. Thresholds on the metrics that lead
BigStats now evaluates bounce rate, deferral rate, complaint rate, unsubscribe rate and delivery rate against thresholds you set per workspace, alongside a watchdog that fires when an event feed goes silent — because an MTA that stopped reporting looks identical to an MTA that stopped sending, and both are incidents.
Deferral rate deserves special attention. A 4xx is the receiver asking you politely to slow down; it is the earliest honest signal you get, and it is the one most senders never alert on because it is not a failure yet. Alerting on deferral trend is the difference between throttling yourself and being blocked.
2. Anomaly detection per sending domain
A static threshold on the workspace average is nearly useless at scale. A 98% delivery rate can hide one mailbox provider rejecting a third of your mail on one domain. So alongside fixed thresholds, BigStats compares each sending domain's current behaviour against its own rolling 7-day baseline and fires when a domain deviates from what is normal for that domain. A domain that always bounces at 3% does not page anyone; a domain that jumps from 0.4% to 1.2% does, even though the absolute number is smaller.
3. Slack and signed webhooks, per alert type
Email is the right channel for a digest and the wrong channel for an emergency. Fired alerts can now fan out to a Slack incoming webhook as a formatted message with a deep link straight to the alert in the feed, and to your own HTTPS endpoint as a JSON payload carrying an HMAC-SHA256 signature header so your receiver can verify it came from us. Both channels have per-alert-type toggles: bounce spikes can wake up the on-call Slack channel while unsubscribe drift stays in email, and the webhook can push straight into PagerDuty, an incident bot, or your own ticketing system.
4. Escalation that knows when to stop
The failure mode of every alerting system is the alert that fires once, into a channel nobody read, at a time nobody was working. Unresolved alerts in BigStats escalate on an interval you choose, up to a reminder cap you choose, and both can be overridden per alert type — a complaint spike can chase every 30 minutes while a deferral blip waits four hours.
Equally important is the stop condition. Escalation cancels immediately when someone acknowledges or resolves the alert in the feed, and it also cancels automatically when the sweep observes that the underlying condition has cleared — the alert is marked resolved and the reason is recorded, so the log distinguishes "a human fixed this" from "it recovered on its own". Auto-resolution is what makes aggressive escalation intervals safe to configure.
5. A daily digest for everything still open
Not every alert is an emergency and not everything gets closed the same day. A configurable daily digest summarises every still-open alert for a workspace with severity counts and deep links into the feed. You pick whether it runs, the hour it sends in UTC, the minimum severity to include, and who receives it. For a lot of teams the digest becomes the standing agenda item for the morning deliverability check-in.
Why this is not optional for a MailOps team
- Reputation is a lagging indicator with a long memory. An hour of unnoticed bad sending can take weeks of clean sending to unwind at a large provider.
- The cost of detection is fixed and the cost of an incident is not. Configuring thresholds is an afternoon; renegotiating with a postmaster team is a quarter.
- Providers reward responsiveness. Being able to show that you detected a pattern, stopped the stream and corrected it within the hour is the substance of a remediation request.
- Attention is the scarce resource. Per-type routing, cooldowns, auto-resolve and a digest exist to make sure the alerts that do reach a human are worth reading.
What to configure first
| Setting | Start with | Why |
|---|---|---|
| Bounce rate threshold | Slightly above your normal peak | Catches list and content problems early |
| Deferral rate threshold | On, even if you've never alerted on it | Earliest available warning signal |
| Per-domain anomalies | Enabled | Finds the one stream hiding inside a healthy average |
| Feed silence watchdog | Enabled | A silent feed is an outage until proven otherwise |
| Slack routing | Critical and warning only | Keeps the channel worth watching |
| Escalation | 30–60 min, 3 reminders | Safe because auto-resolve cancels it |
| Daily digest | One hour before your standup | Turns open alerts into an agenda |
All of it lives in the alert settings panel in your workspace, and the Slack, webhook and digest channels can be test-fired from there before you rely on them. The goal is simple: by the time anyone opens a report, the question should already be "what do we do about this" rather than "how long has this been happening".