What does "container update" in the notifications mean?

[ovizii]

I keep getting those and am unsure what is going on. Do they indicate a container has restarted as nothing else has happened. I basically blink, and I got a handful of those notifications again. :-/

Trying to figure out what they mean and why they keep popping up ;-)

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

Hey @ovizii — great question! These notifications mean Drydock found a newer version of the container's image available in the registry. They do not mean the container restarted or was updated.

Here's what's happening: Drydock periodically checks the image registries for all your watched containers. When it finds a newer tag (e.g., v1.2.3 → v1.3.0) or a digest change (e.g., :latest was rebuilt upstream), it sends a notification like:

New [major/minor/patch/digest] found for container [name]

Your containers are still running the same version — Drydock is just letting you know an update is available. Nothing changes unless you manually update or have configured an action trigger (like docker or dockercompose) to auto-update.

If the notifications feel too noisy, you have a few options:

• Filter by severity — set the trigger threshold to major, minor, or patch to skip less important updates (like digest-only rebuilds)
• Batch mode — set mode: batch to group all updates from a single scan cycle into one notification instead of sending them one-by-one
• Once mode — once: true (the default) means Drydock only notifies once per available update, not on every scan cycle

Coming in v1.5: a new digest mode (mode: digest) that buffers updates over time and sends a single summary on a cron schedule (e.g., a daily email at 8am). Stay tuned!

Check out the trigger configuration docs for more details on mode and threshold.

[ovizii]

I don't think that is what I meant. Here is a screenshot of the notification when clicked upon.

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

You're right @ovizii — my first reply was off-base. Looking at your screenshot, this is a different problem.

What's happening

The "Container Update" notification you're seeing is a lifecycle audit entry, not an "update available" alert. The code path:

1. Every watcher poll cycle, updateContainer() runs for every watched container
2. It unconditionally fires a container-updated event — no check for whether anything actually changed
3. The audit subscription writes a container-update entry with no deduplication
4. The notification bell reads from the audit log and shows every entry

So you're getting N new "Container Update" notifications every poll cycle (default: every minute), for every watched container. That's the flood you're seeing.

The bug

Unlike security-alert (5-min dedup window) and agent-disconnect (1-min dedup window), container-update has zero deduplication. It was likely meant for internal audit, not user-facing notifications.

Fix for v1.5

We'll either:

1. Guard emitContainerUpdated to only fire when the container data actually changed
2. Add deduplication to the audit entry (keyed on container name, window matching the poll interval)
3. Filter container-update out of the notification bell entirely — it's noise, not actionable

Thanks for pushing back on the first answer and posting the screenshot — that made the real issue clear.

[ovizii]

Perfect. That explains why I keep getting new notifications like this :-)

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

v1.5 addresses this — the store now skips redundant container-updated events when nothing actually changed, which should eliminate the notification flooding.

You can try it in v1.5.0-rc.1.

docker pull ghcr.io/codeswhat/drydock:1.5.0-rc.1

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

Glad that cleared it up! Closing this out. If any other notification behavior seems unclear, feel free to open an issue.