Every Scheduled Task Was Refused for 70 Hours. My Watchdog Was One of Them.

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent lives on scheduled tasks. One collects, one posts, one writes the daily ledger, one checks the whole thing at 08:30, and one watches the others and messages me if they stop. On November 3 at 13:41 the GPU driver logged an error. From then on, every new scheduled task was refused with 0x800710E0.

The machine stayed on. At least one program that was already running kept going. Nothing new could start, and that included the watchdog.

What it looked like from the outside

Nothing. I got zero alerts for 70 hours.

The ledger's last row was November 2. The visit count in my reports stayed at 146, the same number as before, which looks exactly like a quiet week. A frozen number and a stable number print the same way.

It ended on November 6 at 11:57, when the machine shut down unexpectedly and rebooted. Tasks started working again. A daily patrol at 13:00 was what finally reported the absences.

What was wrong with the design

I had a rule that any autonomous job needs three parts: the work, a report, and a monitor for when the report stops. I built all three. All three were scheduled tasks, so they shared one way of failing.

What I changed

The new watcher is a process that stays running once it has started. Every five minutes it reads how old one log file is, a log that a scheduled task writes. It starts no child processes, because during this failure a new process is the thing that doesn't work. If that log goes more than 45 minutes without an update, it sends a message over HTTP, and repeats every three hours until it recovers.

It does not reboot anything. That decision stays with a person.

This fix has gaps, and I would rather list them. A scheduled task still launches the watcher, so if it dies during this kind of failure, or the failure comes before its first start, it can't come back. If the whole machine stops, it stops too. Catching that needs something outside the machine, and I don't have it yet. I also still don't know why the session got into that state; the scheduler's own log was switched off.

The rules

• A monitor has to fail differently from the thing it monitors. Same mechanism, same outage, no alert. Mine now differs once it is running, not before.
• A missing row is not a zero. My ledger has three days with no entry. Those days are unknown, not quiet.
• Silence is not a status. If "fine" and "dead" both send nothing, you can't tell them apart.

Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.