Every mail server has an admin console showing queue depth, recent log entries, and blocked-mail counts — but a console someone has to remember to open is not monitoring, it is a lookup tool. Real monitoring means the numbers get checked automatically and something notices before a person does, ideally landing in the same dashboard or alerting stack you already use for the rest of your infrastructure.
Mail infrastructure has a specific failure mode worth watching for deliberately: it can fail quietly. A web server that is down usually announces itself immediately; a mail queue that is slowly backing up, or a spam filter quietly quarantining legitimate mail, can go unnoticed for days.
A short list of the numbers most worth watching, roughly in order of how early they warn you of a problem:
- Queue depth and age. A rising queue, or messages sitting in the queue for hours, is usually the first sign of a downstream delivery problem — a full disk, a blocked destination, or a networking issue.
- Quarantine/blocked volume. A sudden spike suggests either an attack in progress or a rule that just started false-positiving on legitimate mail; a sudden drop to zero can equally mean the filter stopped working.
- Send/receive volume per account. A single account sending far more than its normal pattern is one of the earliest signs of a compromised mailbox — see the blacklist delisting guide for what happens if this goes unnoticed.
- Bounce rate. A rising bounce rate against a list you send to regularly often means the list itself is degrading (old addresses, typos accumulating) before it becomes a deliverability problem.
- Poll via the REST API. Have your own monitoring system call the Developer module's API on a schedule (every few minutes for anything time-sensitive like queue depth) and feed the result into whatever dashboard or alerting tool you already use — Grafana, a status page, or a simple Slack/webhook alert on threshold.
- Scheduled reports. The Reports module generates fully automatic reports on a configurable schedule, exported as HTML with graphs, and archived in compressed form — useful for a daily or weekly human-readable summary rather than a real-time feed, and requires no integration work at all.
Use scheduled reports for the "someone should glance at this weekly" numbers, and API polling for anything that needs an automatic alert within minutes rather than a report someone reads the next morning.
Alerting on every fluctuation trains people to ignore the alert. A few practical rules of thumb:
- Baseline normal behaviour for at least a week before setting a threshold — "queue depth over 50" means nothing without knowing what normal looks like for your volume.
- Alert on trend (rising for 30 minutes) as well as absolute value, since a brief spike during a legitimate mail-merge send is normal and a slow climb during quiet hours is not.
- Separate "needs a human today" from "needs a human this week" — not every anomaly is an incident.
The Developer module's REST API exposes configuration and operational data over JSON or XML that your own monitoring can poll on a schedule, and the Reports module generates fully automatic scheduled reports with graphs on any time period, archived in compressed form. Between the two, mail server health can feed into your existing monitoring stack instead of living only inside the admin console.