Docker Monitoring That Tells You Why the Container Died

A CPU chart stops at the moment a container dies and tells you nothing about why. Fivenines keeps a row for every container on the host, including stopped ones, and records what actually happened to it.

The container table carries the lifecycle state (running, exited, dead, restarting, paused), the exit code, an OOM-killed flag, the HEALTHCHECK verdict where one is defined, restart counts, and how long it has been in its current state.

So "exited (code 137, OOM killed)" replaces "the graph went flat". A container with no HEALTHCHECK reads as having none rather than as healthy - an absence of a signal is never reported as a good one.

Two dedicated triggers watch container state and open one incident per container, named after the container, so two dead containers on one host are two separate alerts.

Container down or unhealthy. Fires while a container sits in a watched state - exited, dead and unhealthy by default, with restarting, paused and created available - and resolves itself when the container recovers. Scope it to named containers or to an image substring so one-shot job containers that exit on purpose do not page you.

Restart loop. A crash-looping container reads "running" on every individual check, which is exactly why polling misses it. This trigger counts the restarts your restart policy performed inside a rolling window - three in sixty minutes by default, tunable up to twenty-four hours - and fires on the pattern rather than the snapshot.

Alerts go out over email, Slack, Microsoft Teams, Telegram, Discord, Pushover, PagerDuty or webhooks. Threshold alerts on container CPU, memory and network are also available; those evaluate the host's containers together, so use a max aggregate to catch the busiest one and reach for the two state triggers when you need the alert to name a container.

A patched host running a two-year-old base image is not a patched system. With Docker monitoring on, Fivenines discovers every image your containers reference and scans the OS packages inside it against known CVEs - Debian, Ubuntu and Alpine layers today.

Findings belong to the image, not to each container. One image running on fifty hosts is one scan and one row, with the affected hosts listed against it, instead of the same CVE repeated fifty times. Images whose containers are stopped - or were never started - are scanned too, because a stale image is exactly the one nobody has looked at.

Nothing runs inside your containers. The agent asks the Docker daemon to stream the package database out of the image, so no shell, no docker exec and no binary inside the image is required - a shell-less image is fine, and so is rootless Docker. An image the scanner cannot read - no supported package manager, or a failed extraction - is reported as not scannable, with the reason, never as zero vulnerabilities.

Image scanning is available on Pro and above and needs a current agent.

Unlike docker stats, Fivenines stores your container metrics with up to 24 months of retention (depending on your plan). Spot memory leaks that develop over days, correlate a restart with the memory spike that caused it, read block I/O as a read-versus-write split per container, and plan capacity based on real data.