How MailTrigger Was Born

Our company uses a bunch of different tools—like Sentry, Jenkins, Monit, Healthchecks, and Uptime. Each of them sends notification emails to admins or engineers (if it can be configured to do so).

The Pain Before MailTrigger

Before MailTrigger, we had a real headache, especially with one service: Monit.

We have many apps that often restart multiple times in a short period. Most of the time, the restarts are harmless. But Monit sends out an email every time a service stops and every time it starts again. And guess what? All those emails go straight to the admin’s inbox.

You can imagine the chaos. Tons of emails piling up, mostly noise. Sometimes we just want to know if any app failed to restart, but the inbox is flooded, and no one wants to read through every single email. So some failed restarts were missed entirely.

That got us thinking: What if we could filter out the noisy restart emails and only get alerts when a service actually fails to come back up?

And Monit wasn’t the only problem.

Sentry was just as bad in its own way. It sends out notifications for logs of all levels—info, warnings, errors, you name it. And every team member receives alerts for all projects, even ones they’re not responsible for. The result? Inboxes stuffed with Sentry emails that are mostly irrelevant. People started ignoring them entirely.

Managing Projects and Notifications Was a Mess

We also manage a lot of different projects, and each project has its own engineers in charge. We use:

• Sentry to track logs,
• Jenkins for automated builds,
• Healthchecks to make sure projects are running, and
• Uptime to monitor connectivity and SSL status.

Originally, we had to set up notification emails in each of those platforms separately. Every time an engineer switched projects or left the team, we had to go into all four platforms and update the email settings manually.

It was such a hassle.

Also, engineers often don’t check their emails. Why? Because their inboxes are flooded with tons of irrelevant messages—things that don’t matter to them or aren't their responsibility. Important alerts get buried, and it takes too long to sift through everything just to find what matters. Eventually, people just stop checking.

We thought: Wouldn’t it be better if we could send alerts directly to Telegram or WhatsApp instead? But Sentry and Jenkins can only send emails... so again, not ideal.

The Idea for MailTrigger

That’s when the idea hit us: What if we had an SMTP server that could receive all these emails, and then decide how to handle them based on some rules?

So we imagined this:

• When Monit sends a notification email, the SMTP server checks if it’s about a real failure or just a normal restart.
• Only the failure alerts get sent to the admin. The rest? Ignored.
• When Sentry sends a log alert, we could route it only to the right person who’s responsible for that specific project.
• This SMTP server could also look at the recipient and forward the email’s content to the right engineer’s Telegram.
• Even better, we could point Sentry, Jenkins, Healthcheck, and Uptime to this one SMTP address. That way, we could manage who gets notified all in one place.

Whenever there’s a team change, we just update the config in one spot—MailTrigger—and we’re done. So much simpler!

And That’s How MailTrigger Was Born

The more we talked about it, the more we felt this was actually a really valuable idea. It solved so many annoying problems for us.

Once we started using MailTrigger, those issues we mentioned earlier? One by one, they disappeared. We were so relieved.

And then we started thinking: Maybe other teams out there are facing the same problems. Maybe... MailTrigger could help them too.

---

In the next post, we’ll walk you through exactly how we connected MailTrigger with tools like Sentry, Jenkins, Healthchecks, and Monit to clean up noisy alerts and get the right messages to the right people — automatically.