Containers & System Health

Updated May 2026

Docker Monitoring

Monitor Docker container CPU %, memory (excluding cache), network I/O, blkio, restart counts, OOM kills, and `HEALTHCHECK` status per container in real time — via the Docker Engine API and cgroup v2.

Start Free Trial View Docs

Why monitor Docker?

Docker is the standard container runtime for local dev, single-host production, and edge deployments. Containers OOM-kill silently, restart in loops, and consume runaway memory or CPU without warning. Per-container monitoring is the difference between 'my site is slow' and 'the cache container has been OOM-killed 47 times in the last hour.'

Auto-discovery of all running containers via Xitogent

Per-container CPU, memory, and network metrics

Container health status and restart tracking

Disk I/O and block device metrics per container

Customizable alert thresholds for every metric

Container lifecycle event monitoring

Works on Linux servers with Docker Engine

1-minute metric collection intervals

What is Docker monitoring?

Docker monitoring, explained

Docker monitoring catches container OOM kills, CPU throttling, crash loops, runaway resource usage, and failed HEALTHCHECK probes before they cascade into user-visible outages. For single-host production (the dominant non-Kubernetes deployment in 2026), Docker Compose stacks, Swarm clusters, and edge/Raspberry Pi setups, per-container visibility is what separates "my site is slow" from "the cache container has been OOM-killed 47 times in the last hour." Xitoring auto-discovers every container, reads the Docker API + cgroup v2 directly, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

Metrics

What we monitor

Container CPU Usage

CPU utilization percentage for each running container.

Container Memory Usage

Memory consumed by each container vs its memory limit.

Memory Limit

Configured memory limit and current usage percentage for each container.

Network RX/TX

Incoming and outgoing network traffic per container.

Block I/O Read/Write

Disk read and write operations per container.

Container Count

Total number of running, stopped, and paused containers.

Container Restarts

Number of restart events per container, indicating stability issues.

Container Health

Health check status for containers with configured HEALTHCHECK.

PIDs

Number of processes running inside each container.

Container Uptime

How long each container has been running since last start.

Triggers & Alerts

Configurable alert triggers

Set up custom triggers in your dashboard to get notified the moment Docker metrics cross your defined thresholds.

Docker monitoring trigger configuration dashboard

Container CPU Usage

warning

Fires when a container's CPU usage exceeds your threshold, indicating resource contention or runaway processes.

Container Memory Usage

critical

Triggers when memory approaches the container limit, risking OOM kills and container crashes.

Container Restarts

critical

Alerts when a container exceeds your restart count threshold, indicating instability or crash loops.

Container Health

critical

Fires when a container's HEALTHCHECK reports unhealthy status.

Network I/O Spike

warning

Triggers on abnormal network traffic patterns, which may indicate data exfiltration or DDoS.

Container Stopped

critical

Alerts when an expected container stops running unexpectedly.

Importance of Docker Monitoring

Docker containers are ephemeral by nature — they can crash, restart, and consume unbounded resources without warning. Without monitoring, memory leaks, CPU throttling, and crash loops can silently degrade your entire infrastructure.

Detect memory leaks before containers hit OOM limits
Identify crash loops and unstable containers immediately
Monitor resource allocation vs actual usage per container
Track network I/O for security and performance analysis
Ensure container health checks are passing consistently

Docker container monitoring dashboard with CPU and memory metrics

Container restart alerts and OOM kill notifications

Why Choose Xitoring

Xitoring delivers enterprise-grade Docker monitoring with zero-config setup. Our lightweight agent auto-discovers all containers on your host, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

One-command install — no sidecar containers needed
15+ global monitoring nodes for low-latency checks
Unified dashboard for hosts, containers, and services
Flexible alerting via Slack, PagerDuty, Telegram & more
Historical data retention for capacity planning & audits

Xitoring Docker host monitoring overview

Use cases

Common Docker monitoring scenarios

Where Docker typically runs today — and what could go wrong if no one's watching.

Small production app on a single server

Many SaaS products, internal tools, and side projects run as a handful of containers on a single cloud server. One misbehaving container can quietly drag down everything else on the box — we catch that before your users do, so a single bad release can't take the whole product offline.

Apps on edge or low-power hardware

Mini-PCs and small devices running smart-home, retail, or field equipment work under tight resource limits. We watch for the warning signs of CPU, memory, and storage stress so the team can step in before a struggling device silently fails on-site.

Container clusters across multiple servers

When containers are spread across many machines, it's easy for some servers to do all the work while others sit idle — wasting capacity and risking overload. We give you one plain view of how the work is distributed so the load can be rebalanced before anything breaks.

Before you start

Prerequisites for Docker

Make sure you've got these in place — most installs are a 60-second job once they are.

Docker Engine 20.10+ (25.x / 26.x / 27.x recommended) running on the host
/var/run/docker.sock present (default Linux installation; rootless mode socket also supported)
Network reachability between Xitogent and the Docker daemon

Setup Guide

Get started in minutes

Install Xitogent on your Docker host

Install the lightweight Xitogent monitoring agent on the host machine running Docker. Xitogent runs as a root system service, so it already has access to the Docker socket — no extra permissions are needed.

curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY

Confirm Docker is running

Make sure the Docker daemon is reachable. A quick `docker ps` on the host confirms the engine is up and the socket is responsive before you wire up the integration.

docker ps

Enable the Docker integration

Run `sudo xitogent integrate` and select Docker. Xitogent will auto-discover all running containers and start tracking them.

sudo xitogent integrate

Configure alert thresholds (optional)

Set custom thresholds for container CPU, memory, restart counts, or health status to get notified when something needs attention.

Verify it's working

Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

sudo xitogent status

Compare

Considering alternatives?

See how Xitoring stacks up against the alternatives for Docker monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

Xitoring vs

Datadog

Pay-per-host pricing gets expensive fast at scale. See where Xitoring delivers the same coverage on a flat plan.

Xitoring vs

New Relic

Full-stack observability without the enterprise tiers, ingestion fees, or seat-based licensing.

Xitoring vs

Grafana Cloud

One tool with one price instead of stitching Prometheus, Loki, and Grafana into a stack you also have to monitor.

See all comparisons

Frequently asked questions

What is Docker monitoring?

Docker monitoring is the continuous collection of per-container performance data from the Docker Engine API and cgroup interfaces — CPU usage %, memory (working set + cache split), network rx/tx, block I/O, PIDs count, restart count, OOM kills, exit codes, and HEALTHCHECK status — combined with alerting when those metrics breach thresholds. It's how teams catch crash loops, memory leaks, and OOM kills before they take down the host.

How do I monitor CPU usage per Docker container?

Read `cpu_stats.cpu_usage.total_usage` and `cpu_stats.system_cpu_usage` from `/containers/{id}/stats` (or `docker stats`). CPU % is computed as `(cpu_delta / system_delta) * online_cpus * 100`. The same number `docker stats` shows. Alert when sustained CPU > 80% of the container's CPU limit (or > 80% of one core if no limit set).

How do I monitor Docker memory usage including cache?

`memory_stats.usage` includes page cache and inactive_file, which inflates the number — a container using 50MB of working set can show 500MB "memory used" if it touched a lot of files. The right calculation: `usage - stats.cache - stats.inactive_file` for true working set. Then compare against `memory_stats.limit` for the percentage. Xitogent does this automatically.

How do I detect Docker container restarts?

Three signals: (1) `docker inspect RestartCount` field per container, (2) `docker events --filter event=restart` for real-time stream, (3) container `StartedAt` timestamp changes. Xitogent watches all three and alerts on restart bursts (e.g., > 5 restarts in 10 minutes = crash loop). Combined with `State.ExitCode`, you can distinguish OOM (137) from app crashes (other codes).

How do I detect container OOM kills?

On cgroup v2 (modern Linux), read `memory.events` in `/sys/fs/cgroup//` — the `oom_kill` counter increments every time the kernel OOM-killed a process in the container. On cgroup v1, `memory_stats.failcnt` from the Docker API tracks the same. Plus `docker inspect` shows `State.OOMKilled: true`, `State.ExitCode: 137`. The `docker events` stream emits `oom` events in real time.

What is cAdvisor and how does it monitor containers?

cAdvisor is Google's open-source container metrics agent — it reads cgroups directly (not via Docker API), so it works for any container runtime (Docker, containerd, podman). Exposes Prometheus-format metrics on `:8080/metrics`. Xitogent reads the same cgroup interfaces directly, so it's wire-compatible with cAdvisor's data — pick whichever fits your stack better.

How do I monitor Docker network I/O per container?

`/containers/{id}/stats` exposes `networks.{interface}.rx_bytes`, `tx_bytes`, `rx_packets`, `tx_packets`, `rx_errors`, `rx_dropped` per network interface attached to the container. Useful for spotting noisy containers, unexpected outbound traffic (security concern), or NIC errors. Xitogent surfaces all of them per container in the dashboard.

Does this work with Docker Compose / Swarm / Podman?

Compose: yes — Xitogent monitors all containers on the host regardless of how they were started. Swarm: yes — install Xitogent on every Swarm node. Podman: not directly (Podman uses a different socket protocol); use the podman REST API integration instead. For Kubernetes, the Docker integration is the wrong fit — use a per-pod monitoring approach with cAdvisor or the kubelet's `/metrics/cadvisor` endpoint.

How often are metrics collected?

Every 60 seconds by default for per-container resource stats, with `docker events` (lifecycle: start/stop/restart/oom/die/kill) streamed in real time. Health-check status updates are captured the moment they happen, so an unhealthy container surfaces immediately rather than at the next polling interval.

Going deeper?