Repository navigation
Known Limits
Behaviour that is known and either deliberate or not fixed yet. Each entry says what you see and what to do.
What you see: after you Reject an update in the queue, the notification digest and the dashboard's digest banner can still list it. If the update is still available, the next scan puts it back in the queue.
Why: Reject removes the queue entry but keeps the record that you were already told about this image, so the next scan does not notify you about it again.
What to do: to stop seeing a version, use Ignore. It removes the update from the queue and from the digest. From v3.1.0 the Reject button's tooltip says so.
A remote container removed outside Sentinel stays on the dashboard for a few minutes (agents before v3.1.0)
What you see: with an agent older than v3.1.0, when a container on that agent's host is removed outside Sentinel (docker rm, Compose, another tool), its row can stay on the hub's dashboard for up to 5 minutes.
Why: those agents send their full container list when they connect, when the hub scans, and otherwise every 5 minutes. From v3.1.0 an agent follows its Docker daemon's events and sends the change within seconds.
What to do: update the agent to v3.1.0, or start a scan.
What you see: if the hub restarts while an agent is updating itself (the hub waits up to 10 minutes for the agent to come back), the "agent updated" or "agent update failed" notification is not sent.
Why: the hub keeps that wait in memory only. The agent still reports the result when it reconnects, so the history entry is correct.
What to do: after restarting the hub during an agent update, check the History page for the result.
Getting Started
Using Sentinel
Multi-Host
Security
Reference