“Everything is running” is the weakest possible claim about a home server. Docker reports Up, the containers answer on localhost, and the whole thing looks fine — right up to the day you leave for a weekend and come back to a stack that died at 2 a.m. with nobody watching. Stability is not a property you can see in a single docker ps output; it is a property you can only demonstrate over time, across reboots, and against a defined pass/fail line.
This page documents the three-layer verification method we used on our Beelink EQi12 (Intel Core i3-1215U, 16 GB RAM, Windows 11 + Docker Desktop) home server, and publishes the actual numbers from each layer. Every value below comes from our public measurement repository (eqi12-measurement-data, CC BY 4.0), with the source file named next to each table. Nothing here is estimated or invented — where we did not measure something, we say so.
If you have not yet built the stack itself, start with the Docker Compose home server stack guide, then return here once docker compose up survives a manual restart. This page is the step after “it works”: proving it keeps working.
Why a single health check is not enough
A container that is healthy at 9 p.m. tells you nothing about three failure classes that only appear over time or across restarts:
- Slow degradation — memory leaks, log files filling the disk, a database slowly bloating. Only a sampled timeline (CPU and available memory over hours) exposes these.
- Boot-order failures — a container that comes up before its dependency, or a service that only fails when Windows starts it automatically rather than when you start it by hand. Only reboot cycles expose these.
- Silent degradation Windows already knows about — services terminating, driver warnings, power events. The event log records these whether you look or not; auditing it turns existing evidence into a verdict.
Each layer targets one class. You do not need fancy tooling for any of them: PowerShell, Docker’s own health status and a text file of timestamps are enough.
Layer 1: the 12.57-hour soak test
The method: while the three-container stack (Nginx, PostgreSQL, Redis) ran its normal workload, a PowerShell loop sampled the machine every 5 minutes and recorded four things per sample — HTTP probe results against the public endpoints, container health/running state, cumulative container restart counters, and CPU percent plus available memory. The run was user-stopped after exceeding the 12-hour minimum, ending at 12.57 hours with 150 samples.
The result, from stability/EQi12_LongStability_12h57_Summary.txt in the measurement repository (the full annotated test log, with screenshots, lives in our 12.57-hour stability lab report — this page focuses on the reusable method and the pass lines):
| Metric | Result over 12.57 h / 150 samples | Pass line |
|---|---|---|
| HTTP probe failures | 0 | 0 |
| Container health/running failures | 0 | 0 |
| Container restart count (max, combined) | 0 | 0 |
| Maximum sampled CPU percent | 52% | < sustained 90% |
| Minimum sampled available memory | 5,472 MB | > 2,000 MB of 16 GB |
| Final live status | 3 containers Up 18 h, all Healthy | All healthy |
Two of these numbers deserve interpretation rather than a checkbox:
- CPU peaking at 52% with the stack idle-ish tells you the box has headroom; the i3-1215U was never the bottleneck during normal operation. What would fail the test is sustained saturation across many consecutive samples, which would indicate a runaway process or an under-provisioned host.
- Available memory bottoming at 5,472 MB is the more meaningful floor. With 16 GB total, the stack plus Windows kept more than a third of RAM free at the worst sampled moment. A downward trend across samples — even a floor that never breaches the pass line — would be the early fingerprint of a leak, which is exactly what the per-sample timeline catches and a single check cannot.
The soak test answers the first question: given no external disturbance, does the stack hold? Zero failures across 150 samples says yes for this workload. The next two layers ask what happens when the machine itself is disturbed.
Layer 2: the 24-hour event log audit
Windows quietly records everything that goes wrong, so before inventing your own monitoring, read what already exists. The audit method: export the System and Application event logs for the last 24 hours, filter to Warning / Error / Critical, group by provider and event ID, then inspect each group once to classify it as benign noise or a real finding. Our capture is stored as stability/EQi12_Event_Summary_24h.txt.
On the EQi12, the 24-hour window contained 4 System and 28 Application warning/error/critical events. The System-side breakdown:
| Count | Provider / ID | Classification | Why |
|---|---|---|---|
| 2 | DistributedCOM 10016 (Warning) | Benign noise | A local activation permission complaint for a COM server — a well-known default-permission artifact on Windows, with no functional impact on a headless Docker host |
| 1 | Kernel-Processor-Power 37 (Warning) | Benign noise | The processor throttling state changed; on a fanless-class mini PC this accompanies normal power management, not instability |
| 1 | Service Control Manager 7024 (Error) | Real finding (action taken) | A vendor updater service terminated with a service-specific error at boot — identified, scheduled for removal from the host, since an updater has no business on a home server |
The 28 Application-side events were dominated by similar vendor and shell noise. The value of the audit is not the count — it is that each recurring provider got a one-time classification. From now on, any new provider appearing in this filter is treated as a signal, because the baseline is known.
Two event IDs always deserve immediate attention on any Windows home server:
- Kernel-Power 41 — the machine lost power without a clean shutdown. If you did not pull the plug yourself, your AC power recovery configuration is about to matter.
- Repeated Service Control Manager 7026/7024 entries — a service failing at every single boot. Ours pointed at a vendor updater; on other machines it is often a failed third-party agent that slows every boot for nothing.
Layer 3: five reboot cycles
The soak test proved the stack is stable while running. Reboot cycles prove it comes back — which is the whole point of a home server you do not sit in front of. The method: script five consecutive restarts, and after each boot record three timestamps — when the OS was up enough to check, when network connectivity (Ethernet up, gateway reachable) was confirmed, and when the media server container actually answered. Source: misc/EQi12_Reboot_5cycles.log.
| Cycle | Boot → network (s) | Boot → Jellyfin answers (s) | Ethernet / gateway |
|---|---|---|---|
| 1 | 67.3 | 188.0 | Up / True |
| 2 | 43.1 | 163.7 | Up / True |
| 3 | 106.0 | 226.9 | Up / True |
| 4 | 58.3 | 178.9 | Up / True |
| 5 | 42.0 | 162.7 | Up / True |
The pass conditions: all five cycles recovered network connectivity unattended, and all five brought the container stack back without manual intervention. Both held. The spread is also informative — boot-to-network ranged from 42 to 106 seconds, roughly a 2.5× spread on identical hardware. Single-timing claims about “my server boots in 40 seconds” are therefore noise; what matters is the range and the recovery rate (5 out of 5), not the fastest sample.
Note the gap between the two columns: network arrives about 2 minutes before Jellyfin does. That is the boot-order reality of a Windows + Docker host — Docker Desktop and WSL2 start, then Compose pulls the stack up, then health checks turn green. If you are designing around this, the Docker Desktop auto-start guide shows how each layer of that chain is configured to survive reboot.
The pass/fail checklist
Putting the three layers together, here is the reusable checklist with the thresholds we actually applied:
| Layer | Check | Pass line |
|---|---|---|
| Soak | HTTP probe failures over ≥12 h | 0 |
| Soak | Container health/running failures | 0 |
| Soak | Container restart count | 0 |
| Soak | Min available memory floor | > ~12% of total RAM |
| Soak | CPU | No sustained saturation across consecutive samples |
| Event audit | Kernel-Power 41 | 0 |
| Event audit | Repeating service-termination errors | 0 (each classified or removed) |
| Event audit | Known-benign providers | Classified once, then ignored |
| Reboot ×5 | Network recovery rate | 5/5 unattended |
| Reboot ×5 | Service recovery rate | 5/5 unattended |
| Reboot ×5 | Boot → service spread | Recorded as a range; regressions judged against your own baseline |
Run the soak test after any major stack change (new container, new volume, Compose file change), the reboot cycles after any boot-configuration change (BIOS settings, auto-start changes, Windows updates that touch drivers), and the event audit continuously as part of monthly maintenance.
What we do not claim
Honesty about scope, because measured data is only useful when its boundaries are explicit:
- 12.57 hours is a floor, not a ceiling. We stopped the run because it exceeded our 12-hour minimum. A leak that surfaces on day 3 would not be caught by this run; the memory floor trend is the metric to keep watching across longer horizons.
- This is one machine and one workload. Three containers and a media server on an i3-1215U box. The method transfers anywhere; the specific numbers do not.
- We have not yet run this verification on the Proxmox side. The same EQi12 now dual-boots Proxmox VE, and an equivalent soak/event/reboot verification under Proxmox is planned but not yet measured. When it exists, it will be published in the same repository.
- Data durability is a separate question. Proving the stack stays up is not the same as proving you can get your data back after it does not. That was covered separately in the backup and restore drill, and both halves are required before trusting a server with anything you care about.
Source data
All numbers on this page are reproducible from the public repository:
- Soak test:
stability/EQi12_LongStability_12h57_Summary.txt— eqi12-measurement-data (CC BY 4.0) - Event audit:
stability/EQi12_Event_Summary_24h.txt(same repository; raw.evtxfiles for the 12.57 h run are included alongside the summary) - Reboot cycles:
misc/EQi12_Reboot_5cycles.log(same repository) - As a side check on the hardware’s media capability during this period, a 2160p60 VP9 hardware-decode test measured 0 dropped frames during the 30-second measurement window (2,048 frames decoded) —
misc/EQi12_YouTube_2160p60硬解测试结论.txtin the same repository
The full build context for this machine — power draw, BIOS configuration, wake-on-LAN and the complete measured summary — lives in the EQi12 Windows home server build log.