Transactional email is silent infrastructure — invisible when it works and catastrophic when it doesn't. Password resets, order confirmations, 2FA codes, and account verification emails are blocking actions for your users. When transactional email fails, users can't log in, can't complete purchases, and can't access their accounts. Worse, the failure is often invisible to your engineering team for hours.
This guide covers why transactional email monitoring matters, what to monitor, and how to use Vigilmon heartbeats and endpoint checks to detect email infrastructure failures before your support queue fills up.
Why Transactional Email Monitoring Matters
Consider what happens when your email service provider (ESP) API goes down:
- Users who click "Forgot password" never receive the reset link
- New registrations stall because verification emails don't arrive
- 2FA codes fail to deliver, locking users out of their own accounts
- Order confirmations go missing, triggering support tickets and chargebacks
- Subscription renewal notices don't send, generating billing disputes
None of these failures produce a visible error in your application. Your app calls the ESP API, the API returns an error (or silently queues and fails), and the user stares at "Check your inbox" indefinitely. Without active monitoring, this can persist for hours before anyone notices.
The asymmetry is severe: email infrastructure failing for 4 hours on a Tuesday afternoon is functionally equivalent to your login page being down for 4 hours. The user impact is the same.
The Transactional Email Stack
Understanding what to monitor requires understanding what can fail:
Your application — the code that calls the email API. Can fail to send API requests due to misconfiguration, environment variable issues, or code bugs.
The ESP API — SendGrid, Mailgun, Postmark, AWS SES, Resend. The HTTP endpoint your application calls to queue an email for delivery. Can be down, rate-limited, or returning errors.
The ESP sending infrastructure — the servers that actually deliver emails to receiving mail servers. Can be degraded, rate-limited, or blocked independently of the API.
SMTP relay — if you route through SMTP rather than HTTP API. The relay server itself can be unreachable.
DNS records — SPF, DKIM, and DMARC records that authenticate your emails. Misconfiguration causes silent delivery failures without any API error.
Receiving mail servers — Gmail, Outlook, corporate mail servers. Can block or defer your emails based on reputation, content, or volume.
Each layer can fail independently and silently.
What to Monitor
1. ESP API Endpoint
Your email service provider exposes an HTTP API that your application calls to send emails. Monitor this endpoint directly to detect ESP outages before they impact users.
Most major ESPs expose status and API endpoints:
- SendGrid:
https://api.sendgrid.com/v3/scopes(requires auth, but confirms API availability) - Mailgun:
https://api.mailgun.net/v3/domains(auth required) - Postmark:
https://api.postmarkapp.com/(returns 200 with auth) - Resend:
https://api.resend.com/emails(health check endpoint) - AWS SES: monitor via CloudWatch or check the SES console endpoint
If your ESP provides a public status page, consider adding their status endpoint as a Vigilmon monitor. When the ESP API is unreachable, Vigilmon alerts you within minutes — before your support queue fills with "I didn't receive my confirmation email" tickets.
Add your ESP API endpoint as a Vigilmon HTTP monitor with a 1–5 minute check interval and webhook alert to your primary Slack channel.
2. SMTP Relay Endpoint (TCP Monitoring)
If your application delivers email through an SMTP relay rather than (or in addition to) an HTTP API, monitor the SMTP server's TCP port directly.
Standard SMTP ports:
- Port 25: traditional SMTP (often blocked by ISPs and cloud providers)
- Port 587: SMTP submission with STARTTLS (most common for application email)
- Port 465: SMTP over SSL/TLS (older alternative)
Add a Vigilmon TCP monitor for your SMTP relay host on port 587. A TCP check confirms the SMTP server is accepting connections — the minimum requirement for email delivery. An SMTP server that isn't accepting connections on port 587 cannot deliver any email.
Vigilmon TCP monitor configuration:
- Host:
smtp.yourprovider.comor your internal SMTP relay hostname - Port: 587
- Type: TCP
- Interval: 5 minutes
- Alert: webhook to Slack
3. Email Queue Heartbeat Monitoring
The hardest email failure to detect is a silent queue drain — your application code runs without errors, calls the ESP API successfully, but emails never arrive at the receiving inbox. This can happen due to:
- Soft bounces accumulating and causing batch deferral
- Reputation-based throttling by receiving mail servers
- Content filters holding messages in quarantine
- Background queue worker crashing after enqueue
The standard solution for this class of failure is heartbeat monitoring: your application sends a test email to a monitoring service (or dedicated inbox) on a regular schedule, and the monitoring service alerts if the heartbeat goes missing.
Vigilmon's cron heartbeat monitoring is designed for exactly this use case:
- Set up a Vigilmon heartbeat monitor — it gives you a unique ping URL
- Write a background job in your application that sends a real test email through your normal email pipeline and, on success, pings the Vigilmon heartbeat URL
- Set the heartbeat interval (e.g., every 10 minutes)
- Vigilmon alerts if the ping doesn't arrive within the expected window
When the heartbeat ping stops arriving, it means your email-sending pipeline has failed — either the background job crashed, the ESP API is returning errors, or the SMTP relay is unreachable. The alert fires before any user sends a support ticket.
This pattern catches failures that API endpoint monitoring alone misses.
4. Bounce Webhook Endpoint
Most ESPs can deliver bounce and complaint notifications to a webhook in your application. These webhooks process delivery failures, unsubscribes, and spam reports — critical for maintaining list hygiene and reputation.
If your bounce webhook is down, bounce notifications accumulate unprocessed. Your application continues sending to hard-bounce addresses, which damages your sending reputation and can result in ESP account suspension or blacklisting.
Add your bounce webhook URL as a Vigilmon HTTP monitor:
- URL:
https://yourapp.com/webhooks/email-bounces - Type: HTTP
- Expected status: 200 (or whatever your webhook returns on a GET health check)
- Interval: 5 minutes
Some bounce webhook endpoints only respond to POST requests. In that case, monitor the application's general health endpoint and treat that as a proxy for webhook availability.
SPF, DKIM, and DMARC: Authentication Misconfiguration
Email authentication records are DNS-based configurations that tell receiving mail servers whether to accept, quarantine, or reject email from your domain. Misconfiguration causes silent delivery failures — your ESP API returns success, but the email is silently dropped at the receiving end.
SPF (Sender Policy Framework): declares which IP addresses and services are allowed to send email from your domain. If you add a new ESP but forget to update your SPF record, emails sent through that ESP may be rejected or spam-foldered.
DKIM (DomainKeys Identified Mail): cryptographic signature on outgoing emails, verified by the receiving server against a public key in your DNS. If the DKIM private key changes (common during ESP migration or key rotation) without a DNS record update, DKIM verification fails.
DMARC (Domain-based Message Authentication, Reporting & Conformance): policy that tells receiving servers what to do with emails that fail SPF or DKIM checks. A p=reject policy with misconfigured SPF/DKIM means your legitimate emails are rejected silently.
How to detect authentication issues:
- Set up DMARC reporting — most receiving mail servers send aggregate reports (RUA) and forensic reports (RUF) to email addresses specified in your DMARC record. Review weekly aggregate reports from services like Postmark's DMARC Digests, Dmarcian, or MxToolbox to catch authentication failures.
- Test your DNS records with MxToolbox, Dmarcian, or
digafter any DNS change or ESP migration. - Monitor SPF/DKIM/DMARC records as part of DNS change management — treat email authentication records as production infrastructure with change control.
Vigilmon heartbeat monitoring catches email delivery pipeline failures; DMARC aggregate reports catch authentication misconfiguration that causes receiving servers to reject or filter your emails silently.
Alerting Configuration
Configure your Vigilmon alerts for email infrastructure with appropriate urgency:
| Monitor | Alert channel | Urgency | |---|---|---| | ESP API endpoint | Slack + PagerDuty | High — immediate action needed | | SMTP relay TCP | Slack | High — email blocked | | Email queue heartbeat | Slack + PagerDuty | High — pipeline stopped | | Bounce webhook | Slack | Medium — reputation risk accumulating |
Use Vigilmon webhooks to post to a dedicated #email-alerts Slack channel where the team can quickly distinguish ESP API outages from bounce webhook health issues.
Practical Setup Checklist
- Add ESP API endpoint as Vigilmon HTTP monitor (5-minute interval minimum)
- Add SMTP relay as Vigilmon TCP monitor on port 587
- Create a Vigilmon heartbeat for your email queue worker
- Write a scheduled job that exercises the email pipeline and pings the heartbeat
- Add bounce webhook URL as Vigilmon HTTP monitor
- Configure DMARC reporting to a monitored inbox or DMARC reporting service
- Test once a month: deliberately delay the heartbeat job and confirm Vigilmon alerts
Conclusion
Transactional email monitoring is not optional for any application where email is a blocking action for users. Password resets, 2FA codes, and order confirmations failing silently is equivalent to your login page being down — the user impact is the same, but the failure is invisible without active monitoring.
The complete transactional email monitoring stack:
- ESP API HTTP monitor: detect ESP outages within minutes
- SMTP relay TCP monitor: confirm the relay is accepting connections
- Email queue heartbeat: detect silent pipeline failures with end-to-end validation
- Bounce webhook monitor: protect sending reputation from accumulating unprocessed bounces
- DMARC aggregate reports: detect authentication misconfiguration that causes silent delivery failures
Vigilmon's heartbeat monitoring is particularly valuable for the silent failure case: it's the only way to detect that your email pipeline has stopped working without waiting for user reports.
Set up email infrastructure monitoring for free at vigilmon.online — heartbeat monitoring is included in the free tier, no credit card required.
Tags: #monitoring #email #devops #transactional-email #deliverability