Feature Request: SMTP delivery in single-day digest form

[begunfx]

Not sure if this is already on the roadmap, but right now I have SMTP email configured. Currently, I'm getting an email for every container/digest update. Would be great to be able to setup a single-day digest delivery of all available updates.

[s-b-e-n-s-o-n]

Thanks for the suggestion!

Drydock already supports batch mode for triggers, which sends a single notification containing all updates instead of one per container. You can enable it for your SMTP trigger by adding:

DD_TRIGGER_SMTP_GMAIL_MODE=batch

In batch mode, after each watcher scan completes, Drydock sends one email listing all containers with available updates — rather than a separate email per container.

What you're describing goes a step further: a scheduled digest that accumulates updates over a time window (e.g. 24 hours) and sends a summary at a fixed time. That's not currently on the roadmap but it's a good idea. The building blocks are there (batch templates, cron scheduling) — it would need a digest buffer that collects update events and flushes on a configurable schedule.

For now, try MODE=batch — it should significantly reduce the email volume. If a true daily digest is still needed after that, we can look at adding scheduled digest delivery as a feature.

[s-b-e-n-s-o-n]

Update: we went ahead and built this. The next release will include a new digest trigger mode:

DD_TRIGGER_SMTP_GMAIL_MODE=digest
DD_TRIGGER_SMTP_GMAIL_DIGESTCRON=0 8 * * *

This accumulates all update events throughout the day and sends a single email at the scheduled time (default 8am daily). If the same container has multiple updates within the window, only the latest is included.

Works with all notification triggers — SMTP, Telegram, Slack, Pushover, etc.

[begunfx]

Sweet! The batch was probably going to work, but that's great. I'll give that a try once the next release comes out. I suspect that would work even better because I can schedule it to send every morning so it will share all updates that have been staggered/collected through the night. Love that flexibility!

[begunfx]

I have DD_TRIGGER_SMTP_GMAIL_MODE=batch as you recommended until the new digest feature is available but I still seem to get individual container available emails as oppose to a batch when a scan runs. I also noticed this happening when I added a new service - I immediately got a new version update (maybe this is expected?).

Currently running on 1.5.0.rc-1

[s-b-e-n-s-o-n]

Thanks for the report. I traced this through the trigger/event pipeline and there were two real bugs in batch mode on rc.1.

1. Agent-sourced container updates were only emitting the single-container event, so batch-mode triggers never saw the full scan batch for remote agents.
2. update-applied / update-failed / security-alert auto-dispatch was wrapping each container as triggerBatch([container]), which still produced one email per event instead of aggregating nearby events.

I've fixed both on feature/v1.5-observability, so this will be in rc.2.

On the "new service" question: yes, that part is expected. When a newly discovered container is first scanned, if Drydock sees it is already behind, it is eligible for an update-available notification immediately. The intended behavior in MODE=batch is that it should be included in that scan's batch email, not sent as its own separate per-container email.

One extra detail: if the emails you were seeing were "update applied" confirmations rather than "update available" scan results, that was also part of the bug above and is included in the rc.2 fix.

If you want, once rc.2 is out please retest with the same DD_TRIGGER_SMTP_GMAIL_MODE=batch config and let me know whether both the scan emails and the post-update confirmations now behave as expected.

[s-b-e-n-s-o-n]

The batch-mode bug you hit in rc.1 was fixed in rc.2 — agent-sourced scan results were not emitting batch events, and nearby events were dispatching individually instead of aggregating. Both are resolved now.

If batch mode is still sending individual emails on rc.2 or later, please open an issue with your trigger config and we'll dig in. Otherwise I'll consider this resolved — thanks for the feature suggestion and the testing!