Monitoring Docker Container Uptime and Health

Docker has transformed how applications are deployed — but containerised workloads have their own failure modes. Containers crash, Docker daemons restart, networks misconfigure, and images change in ways that break running applications.

Effective container monitoring combines Docker's built-in health checking with external uptime monitoring to give you full visibility.

Container Failure Modes

Understanding what can go wrong helps you monitor the right things:

• Container exits unexpectedly — application crashes, OOM kill, or unhandled signal
• Container is "running" but application is broken — the process is alive but not responding correctly
• Network connectivity lost — container running but unreachable from outside
• Docker daemon crash — all containers on the host stop
• Volume mount failure — container starts but can't access required data
• Environment variable missing — configuration-dependent startup failure

External HTTP monitoring catches most of these — if the application isn't responding to HTTP requests, the monitor fails regardless of cause.

Docker Health Checks

Docker supports native health checks in your Dockerfile or compose configuration:

# Dockerfile
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

Or in docker-compose.yml:

services:
  app:
    image: your-app:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

Health check states:

• starting — initial startup period, not yet checked
• healthy — last N checks passed
• unhealthy — N consecutive checks failed

An unhealthy container is still running — Docker won't stop it automatically. You need additional tooling to respond to unhealthy containers.

External HTTP Monitoring for Docker

While Docker health checks monitor internally, external HTTP monitoring confirms reachability from outside the container network:

Monitor: https://yourdomain.com/health
Expected status: 200
Interval: 1 minute

This validates the full path: DNS → load balancer/proxy → Docker network → container → application.

A container can be healthy internally while being unreachable externally due to:

• Misconfigured port mapping
• Firewall rules
• Nginx reverse proxy misconfiguration

External monitoring from Domain Monitor catches what Docker health checks miss.

Container Restart Policies

Configure restart policies so Docker automatically recovers from container failures:

# docker-compose.yml
services:
  app:
    image: your-app:latest
    restart: unless-stopped  # or: always, on-failure:5

Restart policies:

• no — never restart (default)
• always — always restart, including on Docker daemon startup
• unless-stopped — restart unless manually stopped
• on-failure:N — restart up to N times on non-zero exit code

With restart: unless-stopped, a crashed container restarts automatically. External monitoring detects if the restart loop is failing (container keeps crashing) — evidenced by repeated brief outages.

Monitoring with Docker Compose

For multi-service applications, monitor the endpoints of each critical service:

services:
  web:
    ports: ["80:80"]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]

  api:
    ports: ["8080:8080"]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]

  worker:
    # No HTTP port — use heartbeat monitoring instead

For each exposed service, create an external monitor. For background workers without HTTP endpoints, use heartbeat monitoring — the worker pings a URL on each successful job completion.

SSL Certificates in Docker Deployments

If Nginx or another proxy handles SSL termination in your Docker setup, monitor the certificate independently of the container health.

An expired certificate causes the application to be unreachable despite all containers being healthy. SSL certificate monitoring with 30-day advance warnings prevents this.

Docker Swarm and Kubernetes Differences

For Docker Swarm (multi-node Docker):

• Swarm automatically replaces unhealthy tasks (based on health checks)
• External monitoring still provides user-perspective visibility
• Monitor the load balancer or ingress endpoint, not individual nodes

For Kubernetes, see the dedicated guide on monitoring Kubernetes pods — the concepts are similar but Kubernetes has richer health probe options.

Alerting for Container Issues

Combine external monitoring alerts with container event logging:

External HTTP monitoring (via Domain Monitor):

• Alert on: check failure (site unreachable)
• Alert on: SSL certificate expiry approaching

Container-level monitoring (via Docker events or your infrastructure monitoring):

• Alert on: container unhealthy status
• Alert on: container exit with non-zero code
• Alert on: container restart exceeding threshold

The two layers cover different failure modes: external monitoring catches user-visible failures, container monitoring catches failures that haven't yet caused user impact.

Common Docker Monitoring Mistakes

Only using Docker health checks: Internal health checks don't verify external reachability — always add external HTTP monitoring.

No restart policy: Containers that exit don't restart by default. Set restart: unless-stopped for production services.

Health check endpoint doing too much: A health check that calls the database, external APIs, and runs business logic will fail for many reasons unrelated to container health. Keep health checks lightweight — just verify the process is alive and basic connectivity is intact.

Ignoring start_period: Without a start period, health checks run immediately on container startup. A slow-starting application fails its first checks and gets marked unhealthy before it's ready. Always set start_period to cover the application's startup time.

Monitor your Docker-based services externally at Domain Monitor.

Related Articles

• "Monitoring CI/CD Pipelines and Deployment Health"
• "How to Monitor Kubernetes Pod Uptime and Health"
• "Monitoring Apache Web Server Uptime"