The Difference Between Running and Healthy

Imagine you’re in a hospital, connected to a heart monitor.

The monitor tracks your heartbeat. If your heart stops, alarms go off. The medical team responds.

But what if your heart is beating, but you’re unconscious? Or having a stroke? The heart monitor won’t catch that—your heart is fine, but you are not.

A more advanced monitoring system would:

• Check your heart rate (basic liveness)
• Check your blood pressure
• Check your oxygen levels
• Check if you can respond to questions

This gives a fuller picture of your health, not just whether your heart is beating.

Docker’s default behavior is like a simple heart monitor. It only checks: “Is the main process alive?” If yes, the container is “running.”

Health checks are like the advanced monitoring system. They actively test: “Is the application actually working?”

When you start a container, Docker starts a process (PID 1). As long as that process is running, the container state is “running.”

If the process exits (crashes, finishes its task, is killed), the container state becomes “exited.”

This is purely process-based. Docker doesn’t check if the process is doing what it’s supposed to do.

Examples of broken “running” containers:

Example 1: Web server started but crashes on first request

FROM python:3.11
COPY app.py /app.py
CMD ["python", "/app.py"]

The Flask app starts. Docker sees the python process running. Status: “Up.”

But if there’s a bug in a route that crashes the app when a user visits it, the app crashes after startup. Docker still shows “Up” for a few seconds until it notices the process died.

Or worse, if Flask has an exception handler that keeps the process alive but returns errors, Docker will never know there’s a problem.

Example 2: Database connection failing

import psycopg2

# Try to connect to database
conn = psycopg2.connect("postgresql://db:5432/mydb")

If the database isn’t ready, the app keeps retrying. The process is running, but the app isn’t functional.

Example 3: Deadlock or infinite loop

while True:
    # Stuck in an infinite loop due to a bug
    pass

The process is running. Docker is happy. But the application isn’t doing anything useful.

A health check is a command that Docker runs periodically inside the container to verify it’s actually working.

You define:

• What command to run (e.g., curl http://localhost/health)
• How often to run it (e.g., every 30 seconds)
• How many failures before marking unhealthy (e.g., 3 consecutive failures)

Docker runs this command. If it succeeds (exit code 0), the container is healthy. If it fails, Docker marks the container as unhealthy.

The container state changes from:

• starting → healthy (if checks pass)
• starting → unhealthy (if checks fail)
• healthy → unhealthy (if a previously healthy container starts failing checks)

But here’s the key: By default, Docker doesn’t do anything when a container becomes unhealthy. It just marks it.

You can see the health status with docker ps:

CONTAINER ID   IMAGE     STATUS
abc123         my-app    Up 2 minutes (healthy)

Or:

CONTAINER ID   IMAGE     STATUS
abc123         my-app    Up 2 minutes (unhealthy)

In Docker Compose or orchestrators (Swarm, Kubernetes), health checks trigger actions:

• Don’t route traffic to unhealthy containers
• Restart unhealthy containers
• Don’t mark a service as “ready” until health checks pass

Without health check:

Container created → starting → running → exited

With health check:

Container created → starting → (health check succeeds) → healthy
                              → (health check fails) → unhealthy

Once running, the health status can change:

healthy → (checks start failing) → unhealthy
unhealthy → (checks start passing) → healthy

Scenario: Rolling deployment

You’re updating your application. You deploy the new version. The container starts. Docker sees it’s “running” and sends traffic to it.

But the new version has a bug. It starts, but crashes on any request.

Without health checks: Traffic is routed to the broken container. Users see errors.

With health checks: Docker waits for health checks to pass before marking it ready. The broken container never receives traffic.

Scenario: Database not ready

Your app starts and immediately tries to connect to the database. The database is still initializing. Connection fails. App crashes.

Without health checks: App crashes repeatedly. You see a restart loop.

With health checks: The app container waits for the DB container to be healthy before starting. Or if it starts and fails, health checks detect it immediately.

---