A scheduled run that fails is visible. A run that never starts can be caught by watching for its absence. This is the third case, and it defeats both checks: a run that started, ended, reported success, and produced no work.
A one-time task was built for a single purpose: verify that another task's watch had worked on its first night. It ran. Status: succeeded. Duration: seventeen seconds. It reached no verdict and wrote nothing.
Nothing in the monitoring noticed, because there was nothing to notice. The run was not missing. It was not still running. It had not failed.
The entire body of that task's instruction file was a single line telling the run to open that same instruction file and follow it.
The scheduler inlines the file as the prompt. So the run received instructions to read a file whose only instruction was to read that file, found nothing else, and stopped. Correctly, in a sense -- there was nothing to do.
The rule: a scheduled task's instruction file is the prompt. It must carry the work. A file that names itself, or names another file to go and read, is an empty task that will report success forever.
The other way to get a seventeen-second run is a first action that waits. A path outside the working folder, a command whose text changes every run and so can never be pre-approved, an interactive tool. Unattended, that run sits until something times it out.
Both causes look identical from outside: a short run, a success status, no output. The difference only shows in the transcript.
If you monitor scheduled work for absence, you probably classify three ways: missing, stuck, failed. Add a fourth.
EMPTY: the newest run reports success but its elapsed time is implausibly short for that task. Report it exactly like a missing run.
Pick the threshold from what a legitimate early stop costs. On our desk, a task that woke on a weekend, called its data command, saw the market was closed and answered in one line took 67 seconds. A stall took 17. Thirty seconds separates them cleanly: under that, the run has not called a tool and read a result.
Two details that decide whether this works. The new class has to reach the notification, not just the report -- a finding that stays inside a report nobody opens is the same blind spot one step further out. And it has to apply to one-time tasks, which absence monitors usually skip: a recurring task gets another chance in fifteen minutes, but a one-time task's only run is the whole job.
The check occasionally flags a run that legitimately had nothing to do. That costs one line in a report a person reads. The failure it prevents is a day recorded as covered that never happened, discovered a week later. Those are not the same size.
This page is one section of self-verifying-loops, one of the Agent Skills in this set. The skills are plain SKILL.md markdown -- no install, no runtime, no dependency. Drop a folder into ~/.claude/skills/ and invoke it by name.
Four of them are free and need no signup: github.com/resilientmindset01-commits/claude-code-skills-free
Written by ResilientMindset. Not affiliated with, endorsed by, or sponsored by Anthropic. Every claim about Claude Code on this page was checked against Anthropic's own documentation on the date shown.