How Docker Restart Policies Work?

Docker restart policies define how Docker should automatically restart containers when they stop, crash, fail, or when the Docker daemon or host server restarts.

Why Docker Restart Policies are Important

In production environments serving users from USA, UK, India, Europe, and global regions, applications must remain available 24/7.

Containers may stop because of:

• Application crashes
• Memory issues
• Server reboot
• Unexpected failures
• Dependency problems

“Restart policies are one of the simplest forms of self-healing in Docker.”

Real-Time Production Example

Infrastructure:

Nginx
API Gateway
Portfolio Service
Interview Service
Payment Service
MySQL
Redis
    

If the API Gateway crashes:

Application Crash
      |
Container Stops
      |
Restart Policy Triggers
      |
Container Restarts
      |
Service Restored
    

How Docker Restart Policies Work Internally

Docker continuously monitors the container's main process.

Restart Workflow

Container Running
       |
Main Process Exits
       |
Docker Detects Exit
       |
Check Restart Policy
       |
Should Restart?
   |            |
  Yes           No
   |            |
Restart      Container Stays Stopped
    

Important Concept

Docker restart policies monitor the container process, not the application logic itself.

This means:

• If process exits → restart may happen
• If app hangs but process alive → no restart

Docker Restart Policy Types

1. no (Default Policy)

Docker does not restart the container automatically.

Example

docker run nginx
    

Workflow

Container Stops
      |
Docker Does Nothing
    

Best Use Cases

• Development
• Temporary containers
• Batch jobs

2. always Policy

Docker always restarts the container whenever it stops.

Example

docker run --restart=always nginx
    

Workflow

Container Stops
      |
Docker Restarts It
      |
Server Reboots
      |
Docker Restarts It Again
    

Important Behavior

Even manually stopped containers restart after Docker daemon restart.

Production Use Cases

• Critical infrastructure services
• High availability systems
• Monitoring services

3. unless-stopped Policy

Similar to always, but respects manual stop operations.

Example

docker run --restart=unless-stopped nginx
    

Workflow

Container Crashes
      |
Docker Restarts It

Manual docker stop
      |
Docker Will NOT Restart It
    

Behavior After Host Reboot

Best Production Choice

Most enterprises prefer:

restart: unless-stopped
    

because it balances resiliency and operational control.

4. on-failure Policy

Restarts the container only if the process exits with non-zero exit code.

Example

docker run --restart=on-failure nginx
    

Workflow

Application Exits with Error
      |
Exit Code != 0
      |
Docker Restarts Container

Application Exits Normally
      |
No Restart
    

Good for

• Batch jobs
• Scheduled tasks
• ETL jobs

Limiting Restart Attempts

docker run --restart=on-failure:5 nginx
    

Docker stops retrying after 5 failures.

Exit Codes and Restart Policies

Docker Compose Restart Policies

Example

services:

  api-gateway:
    image: api-gateway:1.0
    restart: unless-stopped

  mysql:
    image: mysql:8.0
    restart: always
    

Production Architecture Example

+------------------------------------------------------+
| Nginx                                                |
| restart: unless-stopped                              |
+------------------------------------------------------+

+------------------------------------------------------+
| API Gateway                                          |
| restart: unless-stopped                              |
+------------------------------------------------------+

+------------------------------------------------------+
| Payment Service                                      |
| restart: on-failure                                  |
+------------------------------------------------------+

+------------------------------------------------------+
| MySQL                                                |
| restart: always                                      |
+------------------------------------------------------+
    

How Docker Detects Failure

Docker monitors the main PID inside the container.

Failure Detection Flow

Main Process Exits
       |
Docker Detects Exit Event
       |
Restart Policy Evaluated
       |
Restart Triggered
    

Important Limitation

Restart policies do NOT detect:

• Application deadlocks
• Slow responses
• High latency
• Hung applications

because the process may still be running.

Health Checks vs Restart Policies

Combining Health Checks and Restart Policies

Container Running
      |
Health Check Fails
      |
Container Marked Unhealthy
      |
Orchestrator Restarts Container
    

Real Production Incident Example

Problem

Payment service repeatedly crashed in production.

Behavior

restart: always
    

caused endless restart loop.

Symptoms

• High CPU usage
• Huge log growth
• Server instability

Root Cause

Missing DB_PASSWORD environment variable
    

Solution

• Fixed configuration
• Added startup validation
• Added monitoring alerts

Crash Loop Example

Container Starts
      |
Application Fails
      |
Container Stops
      |
Restart Policy Restarts
      |
Failure Repeats
    

How to Monitor Restarting Containers

Check Restart Count

docker inspect container-name --format='{{.RestartCount}}'
    

View Logs

docker logs container-name
    

Check Events

docker events
    

Docker Daemon Restart Behavior

Host Reboots
      |
Docker Daemon Starts
      |
Restart Policies Applied
      |
Containers Restarted
    

Production Best Practices

1. Use unless-stopped for most services
2. Use health checks with restart policies
3. Monitor restart counts
4. Avoid endless crash loops
5. Use resource limits
6. Implement centralized logging
7. Alert on frequent restarts

When NOT to Use Restart Policies

• One-time scripts
• Database migration jobs
• Temporary debugging containers

Kubernetes vs Docker Restart Policies

Enterprise Monitoring Architecture

+------------------------------------------------------+
| Docker Containers                                    |
+------------------------------------------------------+
| Restart Policies                                     |
| Health Checks                                        |
+------------------------------------------------------+
| Prometheus Metrics                                   |
+------------------------------------------------------+
| Grafana Dashboards                                   |
+------------------------------------------------------+
| Alertmanager                                         |
+------------------------------------------------------+
| Slack / Email Notifications                          |
+------------------------------------------------------+
    

Common Mistakes

• Using always for everything
• Ignoring crash loops
• No health checks
• No monitoring
• No startup validation
• Restarting broken applications endlessly

Interview Answer

Docker restart policies define how Docker automatically restarts containers when they stop, crash, fail, or when the Docker daemon or host server restarts.

Docker monitors the main process inside the container and applies restart rules such as always, unless-stopped, or on-failure based on container exit behavior.

Restart policies improve application resiliency and availability, but they should be combined with health checks, monitoring, logging, and proper error handling for production-grade systems.

Quick Summary Table

Useful Internal Links

• Docker Interview Questions
• Docker Compose Interview Questions
• Kubernetes Interview Questions
• DevOps Interview Questions
• Monitoring Interview Questions
• Microservices Interview Questions

Final Conclusion

Docker restart policies provide automatic container recovery mechanisms that help maintain application availability during crashes, failures, and server restarts.

Modern enterprise systems combine restart policies with health checks, monitoring, centralized logging, and orchestration platforms to build highly resilient cloud-native infrastructure.