iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When a Docker host goes offline, every service whose container runs on that machine stops serving requests. A restart policy can bring an eligible container back after a process exit or Docker daemon restart, but it cannot boot a dead computer, repair failed storage, or restore a broken network. Full recovery requires the host to power on and boot, the Docker daemon to start, each container to have an appropriate policy, and applications to reconnect successfully to their dependencies.
This distinction matters in a home lab because “the container restarted” and “the service is reachable again” are different outcomes. The recovery path depends on which layer failed: electrical power, the host operating system or hardware, Docker itself, a container process, a dependency such as a database, or the local and internet network path.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11What you should expect during an outage
Suppose a mini PC running your home dashboard, media server, password manager, and database loses power. The containers do not continue running somewhere else. They remain on that host, so requests fail until the machine is available again. DNS records, reverse-proxy rules, and container restart settings do not create another copy of the workloads.
After power returns, recovery happens in a sequence:
#1 Best Overall
- 1500VA / 900W RELIABLE BACKUP POWER: The highest VA capacity available for home use; delivers short-term battery power to keep essential devices powered during blackouts, surges, and unexpected power interruptions
- TEN PROTECTED OUTLETS: Power your entire setup with 5 battery backup outlets for essential devices, and 5 surge-only outlets for peripherals. Plus built-in coaxial and Ethernet surge protection for added peace of mind
- AUTOMATIC VOLTAGE REGULATION (AVR): Corrects low voltage brownouts (88V+) and surges (+/-13%) without draining battery. Boosts or trims to stable 120V. Extends runtime for blackouts; Active PFC compatible for gaming PCs
- REPLACEABLE BATTERY & ENERGY STAR UPS: User-replaceable battery (APCRBC124, sold separately) for zero-downtime swaps. ENERGY STAR certified for 92%+ efficiency, cutting energy costs vs standard UPS units
- LCD DISPLAY PANEL: Features an intuitive LCD screen that displays real-time status information including battery charge level, estimated runtime, load capacity, and input voltage for easy monitoring of your power protection system
- Electrical power becomes available. A UPS may bridge a short interruption or keep the machine running long enough for a controlled shutdown, but it does not eliminate other failure causes.
- The host firmware and operating system boot. A failed disk, corrupted filesystem, kernel problem, or hardware fault can stop recovery before Docker is involved.
- The Docker daemon starts. Docker notes that some operating systems, including Ubuntu and Debian, start the daemon automatically when configured normally; other host configurations may require an explicit service setting.
- Docker evaluates each container’s restart policy. Containers with no automatic policy remain stopped. Others are started only under the conditions defined by their policy.
- The application initializes and reconnects. A web service may start before its database is ready, or it may need to retry a network-mounted volume, DNS resolver, or external API.
- The network path returns. A healthy container can still be unreachable if the switch, router, Wi-Fi, firewall, DNS, port forwarding, or internet connection is down.
Consequently, a host reboot can produce a partial recovery: one service may answer immediately, another may wait for a database, and a third may stay stopped because it uses Docker’s default policy.
Identify the failed layer before changing settings
Power loss or an intentional host shutdown
During a power outage or host shutdown, all services on that machine are unavailable. A container policy has no opportunity to act while the operating system and Docker daemon are not running. Once the host is back, the daemon and container policies determine what happens next.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →An intentional docker stop is also significant. Docker’s restart-policy behavior treats a manually stopped container specially: the policy is ignored until the Docker daemon restarts or you manually start the container. This prevents an administrator from stopping a service only to have Docker immediately launch it again.
Host hardware or operating-system failure
A restart policy cannot repair a failed boot drive, overheating CPU, damaged filesystem, faulty memory, or an operating-system crash that prevents Docker from starting. Check the host’s console, firmware diagnostics, system logs, disk health, and Docker service status. If the machine cannot boot, recovery requires host repair or a replacement host and a way to restore the containers and their persistent data.
Docker daemon failure or restart
When the daemon restarts while the host remains up, Docker applies the configured restart behavior to containers. A policy can therefore recover from a daemon restart, but only if the daemon itself can start and the container’s policy covers that event. A daemon restart does not repair an invalid image, a missing bind mount, a permissions error, or a corrupt volume; the container may enter a restart loop or fail immediately.
Rank #2
- 1500VA/1000W PFC Sinewave Uninterruptible Power Supply (UPS): Uses sine wave output to provide battery backup power for Active PFC & conventional power supplies; Safeguards computers, workstations, network devices, and telecom equipment
- 12 NEMA 5-15R OUTLETS: 6 battery backup & surge protected outlets, 6 surge protected outlets; INPUT: NEMA 5-15P right angle, 45 degree offset plug with 5 foot power cord; 2 USB charge ports (1 Type-A, 1 Type-C) quickly charge phones and tablets
- MULTIFUNCTION, COLOR LCD PANEL: Displays immediate, detailed information on battery and power conditions; Color display alerts users to potential issues before they can affect critical equipment and cause downtime; Screen tilts up to 22 degrees
- AUTOMATIC VOLTAGE REGULATION (AVR): Corrects minor power fluctuations without switching to battery power; UL SAFETY CERTIFIED: Product has been tested in a UL certified lab and listed with UL as meeting or exceeding safety standards
- 3-YEAR WARRANTY – INCLUDING THE BATTERY; $500,000 Connected Equipment Guarantee; FREE PowerPanel Management Software (Download)
Container-process failure
If the host and daemon stay available but the main process exits, the container’s policy controls whether Docker attempts another start. An application that exits with status zero may not be restarted by on-failure, while an application that repeatedly exits with a nonzero status can consume resources in a restart loop. Inspect the exit code and logs instead of assuming that repeated restarts indicate a healthy service.
Network or upstream-service failure
Restarting a container does not restore a disconnected network. If your router, switch, VLAN, DNS, VPN, internet provider, or upstream API is unavailable, the container can be running while clients still receive timeouts. Applications should use bounded retries, clear error reporting, and, where appropriate, cached or local data so a temporary upstream failure does not become an endless restart cycle.
Docker restart policies: what each setting actually does
Restart policies apply to containers, not to the host. Docker recommends using restart policies and avoiding a second host-level process manager to start the same containers, because competing supervisors can create conflicting start and stop behavior.
| Policy | When Docker attempts a restart | Important limitation |
|---|---|---|
no |
No automatic restart. This is Docker’s default. | A stopped or failed container remains stopped until you start it yourself or another system starts it. |
on-failure |
After the container’s main process exits with a nonzero status. You can add a retry limit, such as on-failure:5. |
It is intended for failures, not ordinary successful exits. It does not make the host or dependencies available. |
always |
Docker attempts to restart the container whenever it stops, including after the daemon starts again. | A manually stopped container remains stopped until the daemon restarts or you manually start it, and a persistent application error can cause a loop. |
unless-stopped |
Broad automatic restart behavior similar to always. |
A container deliberately stopped by an administrator stays stopped across daemon restarts until manually started. |
Set a policy with docker run --restart, for example docker run --restart unless-stopped ..., or declare it per service in a Compose file. Verify the effective setting with docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' container_name. The policy only describes Docker’s action after an eligible stop; it does not assert that the application is ready or that its data is safe.
What a host reboot looks like in practice
After a normal reboot, first confirm that the host has an address and that you can reach it over SSH or its local console. Then check the daemon:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
- 1500VA/900W Intelligent LCD Uninterruptible Power Supply (UPS): Uses simulated sine wave technology to provide battery backup power to safeguard workstations, networking devices, and home entertainment equipment
- 12 NEMA 5-15R OUTLETS: Six battery backup & surge protected outlets; six surge protected outlets; INPUT: NEMA 5-15P plug with 6-foot power cord; USB charge ports (1 Type-A, 1 Type-C) quickly charge mobile phones and tablets
- MULTIFUNCTION, COLOR LCD PANEL: Displays immediate, detailed information on battery and power conditions; Color display alerts users to potential issues before they can affect critical equipment and cause downtime
- AUTOMATIC VOLTAGE REGULATION (AVR): Corrects minor power fluctuations without switching to battery power; UL SAFETY CERTIFIED: Product has been tested in a UL certified lab and listed with UL as meeting or exceeding safety standards
- 3-YEAR WARRANTY – INCLUDING THE BATTERY; 500,000 Connected Equipment Guarantee; FREE PowerPanel Personal Software (Download)
sudo systemctl status docker
sudo systemctl is-enabled docker
docker infoIf the service is disabled, enable it using your operating system’s service configuration. If docker info reports that the daemon is unavailable, container-level troubleshooting is premature. Resolve the daemon or host problem first.
Once Docker is running, list container state and recent events:
docker ps -a
docker events --since 30m
docker logs --tail 200 container_nameLook for containers in Exited, Restarting, or Created states. An Exited (0) result may be an intentional or successful termination; a nonzero code points to an application failure, configuration error, or missing dependency. Check mounts, environment variables, image availability, and file permissions before repeatedly forcing restarts.
Compose startup order is not the same as readiness
Compose can create services in dependency order, but the short form of depends_on only ensures that the dependency has started. It does not wait for a database to accept connections, a message broker to finish recovery, or an HTTP service to pass an application-level check.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use a health check and the long form of depends_on when a dependent service needs a startup gate. Compose supports the conditions service_started, service_healthy, and service_completed_successfully. A health gate improves initial ordering, but your application still needs retry and error handling for failures that occur after startup.
Rank #4
- 425VA/260W Standby Uninterruptible Power Supply (UPS): Uses simulated sine wave output to provide battery backup power and to safeguard home office, home entertainment including computers, gaming consoles, and broadband routers
- 8 NEMA 5-15R OUTLETS: Four battery backup & surge protected outlets; Four surge protected outlets; INPUT: NEMA 5-15P right angle, 45 degree offset plug with five foot power cord
- ADDITIONAL FEATURES: LED status light indicates Power-On and Wiring Fault, transformer-spaced outlets
- GREENPOWER UPS HIGH EFFICIENCY DESIGN: Reduces power consumption by utilizing a compact charger and power inverter to create an ultra-efficient backup power system for home and office use
- 3-YEAR WARRANTY – INCLUDING THE BATTERY; 75K USD Connected Equipment Guarantee; UL SAFETY CERTIFIED: Product has been tested in a UL certified lab and listed with UL as meeting or exceeding safety standards
services:
database:
image: postgres:16
environment:
POSTGRES_PASSWORD: change-this-value
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
web:
image: example/web:1.4
depends_on:
database:
condition: service_healthy
restart: true
restart: unless-stoppedHere, Compose waits for the database health check before creating web. The service-level restart: unless-stopped controls Docker’s automatic restart behavior for web. The nested dependency option restart: true has a narrower meaning: it can restart the dependent after an explicit Compose operation on the dependency. It does not guarantee that the dependent restarts after the container runtime independently crashes or kills the dependency.
Choose a health command that measures real readiness. A process-exists check can report healthy while the service is still replaying a journal or refusing authenticated requests. Keep credentials out of examples you commit, and confirm that the health command is available in the image.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesUse a UPS for the power scenario, not as a universal fix
A UPS battery backup for a home server can provide limited runtime to the server and networking equipment during a power disturbance. Runtime falls as more equipment is connected, so size the unit from the combined load and the number of minutes you need. A UPS does not protect against a failed motherboard, a bad SSD, a Docker configuration error, or an internet outage.
For a prolonged disturbance, compatible shutdown software can monitor the UPS and initiate a graceful host shutdown before the battery is exhausted. That orderly shutdown reduces filesystem and database risk, but it also means services remain offline until power returns and the host boots again. Include the modem, router, switch, and access point in the load calculation if clients need network access to the server; powering only the server does not preserve the path to it.
A recovery playbook for a home Docker host
- Classify the outage. Ask whether the host has power, whether it boots, whether the Docker daemon is active, whether the container process is running, and whether the network path works. Test from the host itself and from a separate client.
- Recover the host first. Correct power, firmware, disk, operating-system, or thermal problems. Do not keep issuing container commands to a machine that is not reachable.
- Confirm daemon startup. Check the service status and enabled-at-boot setting. Review daemon logs for storage-driver, filesystem, permission, or configuration failures.
- Inspect all containers. Use
docker ps -a, then inspect restart policy, exit code, mounts, and recent logs for each affected service. - Start a deliberately stopped service manually. If an administrator stopped it, the restart policy may be intentionally suppressed. Use
docker start container_nameafter confirming that the stop was not protecting data or the host. - Validate dependencies. Confirm that databases, queues, mounted filesystems, DNS, certificates, and secrets are present and ready. A health check can control initial Compose order, but application retry logic handles later interruptions.
- Test reachability externally. Check the service from another device, verify DNS resolution and firewall rules, and test the reverse proxy or port mapping rather than relying only on a local container status.
- Record the cause and recovery time. A short incident note helps distinguish a one-time power event from a repeating disk, thermal, network, or application problem.
Hardening so an outage is survivable
Make restart intent explicit
Declare a per-service policy in Compose instead of relying on the default. Use on-failure when a successful exit should remain stopped, and use unless-stopped for long-running home services that should return after a host or daemon restart unless you intentionally stopped them.
Best Value
- 12 NEMA 5-15R OUTLETS: Six battery backup & surge protected outlets; Six surge protected outlets (Three ECO controlled); INPUT: NEMA 5-15P right angle, 45 degree offset plug with five foot power cord
- MULTIFUNCTION LCD PANEL: Displays immediate, detailed information on battery and power conditions
- ECO MODE: When the UPS detects a computer is off or in sleep mode, it will automatically turn off power to computer peripherals connected to ECO mode outlets, reducing power usage and lowering energy costs
- 3-YEAR WARRANTY – INCLUDING THE BATTERY; $100,000 Connected Equipment Guarantee and FREE PowerPanel Personal Edition Management Software (Download)
Protect persistent data separately
Container recreation is not a backup. Keep databases and important files on deliberate volumes or bind mounts, document their locations, and test restoring them on a second host. A restart policy can repeatedly launch a container with an empty volume or a damaged database if the underlying storage is not protected.
Control restart loops
Use an on-failure retry limit where an unhealthy application should not restart forever. Alert on repeated exits, high restart counts, and failed health checks. A service that flaps can overload a database, fill logs, or hide the original configuration error.
Design for dependency loss
Set connection timeouts, exponential backoff, and a maximum retry interval in the application. Decide whether the service should serve cached data, reject requests clearly, or remain degraded while a dependency is unavailable. Do not treat a green container state as proof that every upstream function works.
Test the actual failure modes
Schedule controlled tests: reboot the host, restart the Docker daemon, stop a container, disconnect the network path, and simulate a dependency that is slow to become ready. Verify expected container states, health transitions, alerts, data integrity, and external access. Perform tests during a maintenance window and keep a console or alternate access path available.
Troubleshooting by symptom
| Symptom | Likely layer | Next check |
|---|---|---|
| The host is unreachable and has no console output | Power, hardware, or boot failure | Check UPS and power connections, console or firmware output, disk health, and physical temperature. |
| The host is reachable but every container is stopped | Docker daemon or disabled startup | Run systemctl status docker, inspect daemon logs, and verify the service is enabled. |
| One container is repeatedly restarting | Application exit, bad configuration, or missing dependency | Read its exit code and logs, inspect mounts and environment, and review the restart policy. |
| The database is running but the web service fails at boot | Readiness or connection handling | Add a meaningful health check, use condition: service_healthy, and configure application retries. |
| The container is healthy locally but unreachable from another device | Network, firewall, DNS, proxy, or router | Test the host port locally and remotely, then check addressing, name resolution, firewall rules, and upstream equipment. |
| Services return after a manual start but not after reboot | Default or unsuitable restart policy, or daemon startup | Inspect the policy and confirm Docker starts automatically on the host. |
When one host is not enough
Restart policies and a UPS improve recovery from common single-host interruptions, but they do not provide high availability. If a failed host must not take services offline, you need a second host, replicated data, a tested failover method, and a network design that can direct clients to the surviving instance. That adds operational complexity: state synchronization, split-brain prevention, secret distribution, backups, monitoring, and regular failover tests.
For many homes, the practical baseline is simpler: automatic Docker startup, explicit per-service restart policies, health-aware Compose dependencies, tested backups, UPS coverage sized for the server and network equipment, and an external monitoring check. This combination addresses different failure layers without pretending that any single setting can repair the entire stack.
The bottom line
A Docker host going offline takes its hosted services offline with it. Containers can return automatically only after the host and Docker daemon are functioning, and only when each service’s restart policy permits it. Compose health checks improve dependency startup, while application retries handle later failures. A UPS can bridge a short power event or trigger a graceful shutdown, but it cannot solve hardware, software, or network failures. Treat recovery as a layered process—power and host, daemon, container, dependencies, then network reachability—and your home services will be far more predictable when something breaks.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
