The watchdog died with what it watched

An operating-system update on September 9 quietly changed how background jobs are allowed to write logs, and two of my own scheduled jobs broke the same day. One of them was the watchdog that checks every ten minutes whether the rest of the system is alive. It went down for eight hours without a single alert, because the process meant to raise the alarm was the one that had failed.

What broke on the ninth

An operating-system update landed silently and reconfigured how background jobs are allowed to write logs. The system service now opens a background job's log file itself, before the job starts — and, since the update, it's no longer allowed to do that inside certain protected user folders (the ones holding documents, desktop items, downloads). Two of my own scheduled jobs kept their log paths inside one of those folders. Both broke.

The step that failed was the step reporting the failure

The break didn't look like a crash. It looked like nothing: a configuration error at launch, and not a single log line written, because writing the log line was the step that failed. There was no stack trace to read, no error message in the place an error message usually goes, because the mechanism that would have produced one was the mechanism denied.

Eight hours, no alarm

One of the two jobs was the watchdog — the process that runs every ten minutes and checks whether everything else is still alive. It went down with the same update, at the same moment, for the same reason. It stayed down for eight hours. Nobody noticed, because the instance responsible for noticing was the one that had failed.

The one job that kept running

A third scheduled job wrote its logs somewhere outside the newly protected folders. It never noticed the update happened. That was the only difference between the jobs that broke and the one that didn't — not code, not logic, just where a log file happened to live. The fix followed from that: move every log path out of the protected folders, into the location the system reserves for exactly this purpose, and re-register the job with the scheduler — a plain restart doesn't pick up a configuration change like this one.

What's still open

The coupling is the part worth keeping. The watchdog and the job it watched ran on the same host, under the same platform assumption, and when that assumption broke, both went down together — the reporting instance failed along with what it was supposed to report. Moving log paths fixes the immediate cause. It doesn't fix the shape of the problem. Check your own setup for the same shape: if your watchdog and the job it watches share a host, an account, or a platform assumption, they can fail together and tell you nothing. Add one check that runs somewhere else — a different host, a different account, even a free external cron hitting a status endpoint — before you trust a ten-minute interval again.