Docker monitoring
On Linux hosts with Docker installed, the agent’s Docker check runs every 30 seconds and reports what the daemon sees. Nothing needs to be configured: the check is part of the Default Linux Profile and turns itself off on hosts where Docker is not available. It is not available on Windows.
What is reported
Section titled “What is reported”Per container:
| Field | Notes |
|---|---|
| Name, ID, image | As Docker reports them |
| State | running, exited, paused, dead, created, restarting |
| Health | healthy, unhealthy, starting, or none when the image has no healthcheck |
| Ports and networks | Published ports and attached networks |
| Compose project and service | From the Compose labels, when present |
| CPU %, memory used, memory limit, memory % | For running containers |
| Created at |
Per host: whether Docker is available, the daemon version, and counts of total, running, stopped, and unhealthy containers. The total count is charted on the Metrics tab; the rest is shown live on the Docker tab of the server page, with a running/stopped filter and columns for name, image, status, health, CPU, memory, ports, and Monitor.
Events and alerts
Section titled “Events and alerts”The check compares each run with the last and emits an event on change:
| Event | Severity | When |
|---|---|---|
| Container started | notice | A container moved to running |
| Container stopped | warning | A running container exited, or disappeared |
| Container died | critical | A container reached the dead state |
| Container changed | notice | Image, ports, or other attributes changed |
| Required container stopped | critical | A container on the required list is missing or not running - repeated every cycle until it is back |
Events appear on the host’s Agent tab timeline with their priority and are part of the context Kicker reads when triaging anything else on the host. They do not page by themselves today. To be paged when a container’s service is down, put an HTTP or TCP monitor on what it serves, or a heartbeat inside a job that runs in it.
A container in a restart loop shows as restarting on the Docker tab.
There is no restart-count metric today.
Required containers
Section titled “Required containers”The Monitor toggle on the Docker tab marks a container as required. The list is stored per host, and any required container that is not running records a critical event every cycle until it is, so the gap is obvious on the timeline and to Kicker. Use it for the containers that define the host’s job - the database, the reverse proxy, the application - and leave one-off and batch containers off it.
The same list is readable and writable over the API
(/hosts/{uuid}/required-containers) and readable by AI assistants
through the get_server_containers MCP tool; see the
MCP tool reference.
Container security
Section titled “Container security”Separately from the monitoring check, the eBPF security module watches container activity - a shell spawned inside a container, a process escaping a namespace, an image pulled from a registry outside your allowlist. Those are security detections rather than monitoring events; see Security events and the container registry allowlist under Customizing detection rules.
Services from containers
Section titled “Services from containers”Once a day Kicker proposes services from Compose projects and container port maps, so a Compose stack turns into a service with its hosts, containers, and monitors linked, ready to confirm.
Troubleshooting
Section titled “Troubleshooting”- Docker tab says Docker is not available. The agent runs as root
and shells out to the
dockerCLI. Check thatdocker psworks on the host and that the CLI is on the path the service sees. - Resource figures are blank. CPU and memory are only collected for running containers.
- Compose project is empty. The labels are read from the container; containers started outside Compose have none.