Monitoring GreenArrow Email Engine: from event notifications to early warnings.
GreenArrow's Event Notification System already emits every signal you need. Here's how to monitor GreenArrow delivery health properly: which events matter, why deferrals move first, how to cut by VMTA and sending IP, and how to get alerted before a bounce wave.
GreenArrow Email Engine gives operators a lot out of the box: a web interface, per-mailing statistics and an Event Notification System that can push every delivery, deferral and bounce to an endpoint of your choosing. What it does not give you is a monitoring strategy. Per-mailing stats tell you how last night's send went. Deliverability work needs to know what Gmail, Microsoft and Yahoo are deciding about your mail right now — per VMTA, per sending IP — and to be told when that changes.
This guide covers what to monitor on GreenArrow, which events carry each signal, and how to turn the Event Notification System into an early-warning system instead of an archive.
The events that matter
GreenArrow's Event Processor can deliver many event types. Delivery health comes down to a core set — get these flowing and every metric worth tracking can be computed from them:
| Event | What it tells you | Priority |
|---|---|---|
| Delivery (accepted) | The receiving server accepted the message — delivery rate per provider and IP | Required |
| Deferral | A 4xx temporary failure with reason text — the earliest warning a sender gets | Required |
| Bounce (hard / soft / block) | A permanent failure with SMTP code, DSN status and diagnostic text | Required |
| Spam complaint (FBL) | A feedback-loop complaint — the reputation signal providers weight heaviest | Recommended |
| Unsubscribe | List-health context alongside complaints | Optional |
Make sure each event carries the mailing or campaign ID, the VMTA (or binding) and the sending IP. Those three fields are what let you isolate a problem instead of averaging it away. Our GreenArrow setup guide shows the exact Event Processor configuration.
Deferrals move first
Most GreenArrow operators alert on bounces, if they alert at all. Bounces are a lagging indicator: by the time a provider hard-rejects, reputation damage is already done. Deferrals are the provider telling you to slow down before it stops asking nicely — "421 4.7.0 try again later" from Gmail or a Microsoft throttle is the moment to act.
Raw deferral counts are noisy, though. A healthy stream defers some mail every day, and most deferrals recover on retry. Useful monitoring tracks the deferral rate against your own baseline and counts each message once — a message that deferred four times before delivering is one delivered message with four attempts, not five events of bad news. What deserves attention is the set of messages still unresolved after retries, and that set should shrink automatically as retries succeed.
Cut by VMTA, IP and receiving domain
A 98% delivery rate across the whole engine can hide one provider rejecting a third of your mail from one IP. GreenArrow's strength is fine-grained routing, so monitoring needs the same granularity:
- VMTA and binding — a new IP warming in one binding behaves nothing like your seasoned pool, and should be judged separately.
- Sending IP — reputation lives at the IP (and /24) level; you need to see which address is moving, and whether it just landed on a blocklist.
- Receiving domain and MX — Gmail, Microsoft and Yahoo enforce different policies; corporate mail behind Proofpoint or Mimecast fails differently again.
- Mailing — so one bad send shows up as itself, not as a smear across the day.
- Windows shorter than a day — 1, 3 and 6-hour views catch an incident while it can still be fixed.
Read what the receiver said
GreenArrow records the SMTP reply, the enhanced DSN status and the diagnostic text on every bounce. That text separates "5.1.1 user unknown" (a list problem) from a policy or blocklist rejection (a reputation problem) from a rate limit (a pacing problem). Grouping and ranking those diagnostics turns a red number into a named cause — and it is exactly what a postmaster desk asks for when you request remediation.
From watching to being told
The goal is not another dashboard to remember to check. It is alerts on the signals that move first — deferral rate and per-domain bounces — delivered to the channel someone watches, escalating until an owner picks the incident up, and going quiet once the condition clears. Watch for silence too: a GreenArrow node that stopped sending events looks identical to one that stopped sending mail.
That is what BigStats adds on top of GreenArrow: point the Event Notification System at your ingest URL and you get per-provider delivery health, deferral recovery tracking, bounce forensics, VMTA and sending-IP breakdowns, hourly blocklist checks and alerts with escalation — read-only, with no change to how GreenArrow sends. See the GreenArrow overview or go straight to the setup guide; the 7-day trial does not ask for a card.