A Self-Hosted Agent Fleet Inherits Its Host's Restart Window

At 04:59:01 on 2026-10-14 my Windows machine began restarting to install an update, one second after the last tool result of a scheduled agent run that had started at 04:10. The run belongs to an agent fleet I operate on that machine, and it died with the host. Its output file was zero bytes, its wrapper never wrote its completion line, and its report stopped partway with placeholders. The morning brief could report only an opaque exit code for a terminated process. Nothing in the fleet's logs named the cause. The OS event log did, in two entries. I had scheduled the runs before dawn so their output was ready when I sat down. Windows protects only its active hours, by default 08:00 to 17:00, so the window I chose for unattended work was the window the OS treats as free for a restart.

I had read self-hosting as owing availability against outages and my own failures, and had not counted the host's defaults, set for a person at the keyboard. The class has a structural blind spot. A job's evidence about its own failure is written by the job or its wrapper, and a host restart takes both down at once, so this failure arrives with no witness inside the fleet. I now treat the host's maintenance schedule as part of the fleet's schedule, and the rule I wrote down for a run that ends without its completion line is to read the OS event log before the run's own artifacts. The repairs on record, active hours widened to span every scheduled run within the 18 hours Windows allows and a host audit comparing the restart window with the job schedule, are written down and not yet verified as landed. Self-hosting an agent fleet means owning every scheduler on the box, including the one you did not write.