Monitoring KumoMTA: what to watch beyond the logs.
KumoMTA's logs are excellent — and they are not a monitoring strategy. Here's what delivery-health monitoring on KumoMTA actually requires: the log records that matter, the signals that move first, and how to turn TransientFailure noise into an early-warning system.
If you run KumoMTA, you already have good logs. The log hook streams a structured record for every reception, delivery, bounce and transient failure, and for day-to-day operations that is genuinely useful. But a log stream answers the question "what just happened to this message?" Deliverability work asks a different question: "what are the mailbox providers deciding about my mail, and is it getting worse?" That second question is a monitoring problem, and it cannot be answered by tailing a log file — no matter how nice the log format is.
This guide covers what to monitor on KumoMTA, which records carry each signal, and how to wire it up so the numbers come to you instead of the other way around.
The records that matter
KumoMTA's log hook can emit many record types, but delivery health comes down to a core set. Get these flowing and you can compute every metric that matters:
| Record type | What it tells you | Priority |
|---|---|---|
| Reception | A message was accepted for delivery — the denominator for every rate you compute | Required |
| Delivery | The remote server accepted the message — delivery rate and per-provider placement | Required |
| Bounce | A permanent failure with the receiver's SMTP code and diagnostic text | Required |
| TransientFailure | A 4xx deferral — the earliest warning signal a sender gets | Required |
| Expiration | A message aged out of the queue after repeated deferrals — a deferred-then-lost message | Recommended |
| OOB | An out-of-band bounce reported after acceptance | Recommended |
| Feedback | A feedback-loop complaint — the reputation signal providers weight heaviest | Recommended |
The hook itself is a few lines in init.lua: kumo.configure_log_hook with the headers you want carried through (campaign and mailing IDs are worth including), pointed at an HTTP endpoint that accepts the records. Our KumoMTA setup guide has the full snippet, including a dry-run mode that validates your payloads before anything is stored.
The signal most KumoMTA operators miss: TransientFailure
Ask a room of senders what they alert on and most will say bounces. Bounces are a lagging indicator — by the time a provider is hard-rejecting your mail, the reputation damage is done. The leading indicator is the 4xx. A TransientFailure is the receiver asking you to slow down, politely, before it stops asking politely.
Two things make deferrals hard to use raw. First, they are noisy: a healthy stream defers some mail every day, so a flat threshold pages you constantly. Second, most deferrals resolve themselves — the retry succeeds an hour later and the incident that mattered is the one where they didn't. Useful deferral monitoring therefore tracks two things: the deferral rate against your own rolling baseline (so normal-for-you doesn't page anyone), and the count of messages still unresolved after retries (so recovered deferrals stop demanding attention the moment they recover).
Aggregate numbers hide the incident
A workspace-wide 98% delivery rate can contain a mailbox provider rejecting a third of your mail on one sending domain. Every metric above needs to be cut by the dimensions where problems actually live:
- Receiving domain and MX — Gmail, Microsoft and Yahoo enforce different policies and break at different times.
- Sending IP and IP pool — shared reputation means one bad stream drags the pool, and you need to know which IP is moving.
- Campaign and mailing — carried through as log-hook headers, so a single bad blast is visible as itself, not as a smear across the day.
- Time windows shorter than a day — deliverability teams work in hours; a daily report tells you yesterday was bad.
What the receiver actually said
A bounce count is a number; a bounce record is a sentence the receiver wrote you. The SMTP code, the enhanced (DSN) status code and the diagnostic text distinguish "5.1.1 user unknown" (a list problem) from a reputation block (a you problem) from a rate limit (a patience problem). Monitoring that groups and ranks the actual diagnostic text turns a red number into a named cause — and it is exactly the detail a postmaster team asks for when you file a remediation request.
From watching to being told
The end state is not a dashboard you remember to check — it is alerts that fire on the metrics that move first (deferrals and per-domain bounces), reach the channel someone actually watches, escalate until a human owns the incident, and go quiet the moment the condition clears. A feed-silence watchdog matters too: an MTA that stopped reporting looks identical to an MTA that stopped sending, and both are incidents.
That is the layer BigStats adds on top of KumoMTA: the log hook streams records in, and you get per-provider delivery health, deferral recovery tracking, bounce forensics, sending-IP and blocklist monitoring, and alerts with escalation — on the mail you actually send, not a seed-panel estimate. The setup guide takes about ten minutes, and the 7-day trial does not ask for a card.