Hey, I wanted to suggest an optional batching mode for email alerts.
Right now, if several services start failing around the same time, Gatus sends one email per alert. That works fine for isolated issues, but it can get noisy pretty quickly when multiple things break at once.
A few common examples:
- several services are running on the same server and that server has an issue
- an automatic update breaks multiple services at once
- multiple services depend on one shared service, so one failure causes a bunch of alerts
- a reverse proxy, DNS, database, or auth service goes down and half the stack starts failing
In those cases, getting a flood of individual emails can be a bit much. A short batching window for email alerts could make that easier to manage.
What I had in mind:
- keep the current behavior as the default
- add an optional config block under
alerting.email.batch
- when enabled, collect email alert events for a short time window and send them as a single summary email
- include separate sections for triggered and resolved alerts
- dedupe repeated alerts for the same endpoint/state within the window
Something like:
alerting:
email:
from: alerts@example.com
to: you@example.com
host: smtp.example.com
port: 587
username: alerts@example.com
password: secret
batch:
enabled: true
window: 30s
max-alerts: 50The main goal is just to reduce alert spam during broader incidents without changing the default behavior for everyone else.
I already have a working implementation locally and tested it with real SMTP delivery. There’s now an open PR for it here: #1623
Hey, I wanted to suggest an optional batching mode for email alerts.
Right now, if several services start failing around the same time, Gatus sends one email per alert. That works fine for isolated issues, but it can get noisy pretty quickly when multiple things break at once.
A few common examples:
In those cases, getting a flood of individual emails can be a bit much. A short batching window for email alerts could make that easier to manage.
What I had in mind:
alerting.email.batchSomething like:
The main goal is just to reduce alert spam during broader incidents without changing the default behavior for everyone else.
I already have a working implementation locally and tested it with real SMTP delivery. There’s now an open PR for it here: #1623