An update restarted my computer, every night job skipped, and the watchdog skipped with them

What I expected

My content pipeline publishes on a fixed schedule from a Windows computer at home. In mid-August the schedule had seven slots a day, three of them overnight: 02, 04 and 06. Each slot is a separate scheduled task that takes the next prepared item from a queue and publishes it. Prepared items have a 24-hour lifetime on the platform, so a slot that does not run is not just late; if nobody notices, the item can expire.

I had already learned that sleep breaks schedules, so the overnight tasks had two settings switched on:

• Wake the computer to run this task, for when the machine has gone to sleep.
• Run the task as soon as possible after a scheduled start is missed, for when it was off.

On top of that sat a watchdog: a separate task at 08 every morning that compares each slot with its last scheduled time and messages me only if a slot did not run. It existed precisely because an earlier overnight slot had been lost and nobody knew until morning.

So I expected one of three things on any bad night: the jobs run, or they catch up, or the watchdog tells me.

What actually happened

None of the three. The record from the computer’s own logs:

Time	What happened
01–01	Windows Update forced three restarts to finish a planned update
01	Startup completed. No sleep after that: the computer stayed on all night
01–09	Nobody logged on. The desktop did not start until 09
02, 04, 06	The three overnight slots did not run. Their last-run time was never updated, and the scheduler moved each one’s next run to the following day
08	The watchdog did not run. No message
09–09	I found the five waiting items and published them by hand

The next automatic slot was at 15. By then the waiting items would already have expired. They were saved because I happened to look in the morning, not because anything told me to.

Why

Two things went wrong, and the second one is the one worth writing about.

The jobs needed a logged-in user. Every task was set to run only while a user is logged on. Locking the screen or sleeping does not matter for that setting, but after a restart nobody was logged on until 09. The two settings I relied on did nothing here, and that is by design: “wake to run” is for a machine that is asleep, and “run after a missed start” is for a machine that was off. This machine was neither. It was on, waiting at the login screen.

The watchdog had the same weakness. It was a scheduled task on the same computer with the same “only while logged on” setting. The one situation that stopped every slot also stopped the check that was supposed to notice stopped slots. It was built to catch silence, and it went silent at the same moment.

A watchdog that fails together with the thing it watches gives you no signal on the nights you most need one, and on every other night it tells you all is well, which makes you trust it more.

What I changed

1. All eight tasks, the seven slots and the watchdog, now run whether or not anyone is logged in. On Windows this is a different logon type for the task, so a restart at night no longer stops them.
2. The scheduler’s history log is on. It is off by default, which meant I could not see afterwards why a task had not run. Now the scheduler keeps its own record of what each task did.
3. I check the live setting instead of my notes. I wrote down on August 13 that the change was made. On August 20 I checked the tasks directly: all eight still had the old setting, and the history log was still off. Changing the logon type needs administrator rights, and from a normal shell the command fails with “Access is denied”. I re-applied it from an administrator shell and confirmed each task afterwards, including that its schedule, wake setting and time limit were unchanged.

The watchdog still runs on the same computer as the jobs, so a machine that is switched off would still silence both. The restart case is closed; that one is not, and I know it.

What this has to do with hiring someone

If a freelancer had built these jobs for me, this would have passed every test I knew to ask for at the time: scheduled runs, a run after sleep, an alert when a slot is missed. The gap only appears with a combination nobody demos: a restart, and then nobody logs in.

So when you brief a workflow automation, ask two things in writing. First: what does each job need in order to run (a logged-in user, an awake machine, a network connection, a valid login), and which of those has been tested? Second: what does the watchdog have in common with the jobs it watches? A good answer names something different, such as a check that runs elsewhere or one that looks at the published result rather than the machine. The basics page on heartbeat monitoring explains why a check that expects a regular “I’m alive” signal catches this kind of silence.

The restart test belongs next to the sleep test in the acceptance checklist for unattended automations. And if the job prepares work that expires, ask what happens to it when a run is missed. Mine had a deadline, and only luck caught it in time.