Claude Code line · stop 14 of 16 · 18 min · members
Scheduled jobs, launch agents and the small decisions that keep them alive after your machine restarts.
Free with an account
Membership is free: an account opens all 86 script pages. The Lab, Studio Canvas and the paid guides need the $99 pass, paid once. Already signed in on this browser? The page opens by itself.
The pattern
It works for a month, then quietly stops, and nobody notices for another three.
The scheduled job that ran perfectly stops after a restart, an update, or a moved folder. Because it produced its output silently into a directory, its absence is silent too.
By the time you notice, you have lost months of whatever it was doing and you no longer remember how it was set up.
The causes are a small, repeating set — and each has a defence that costs a few minutes at build time. What follows is the list, in the order these things actually fail.
Cause one
A scheduled job runs with almost none of your shell's setup.
Your interactive shell has a configured path, environment variables and a working directory. A scheduled job typically has none of them. The command that works when you type it fails when scheduled, with an error about a binary that is definitely installed.
The defence is to assume nothing:
Test by running it the way the scheduler will, not the way you would.
Cause two
Output goes nowhere, so a failure is indistinguishable from a success.
Send both output streams to a log file with a timestamp, always, whether the run succeeded or not.
{ date; /usr/local/bin/thing; echo "exit=$?"; } \
>> /Users/me/logs/thing.log 2>&1Then, separately, make success visible somewhere you will look — a line in a file you check, a notification, a timestamp the job touches.
The property you want is that silence means broken. If the job's normal behaviour is to produce nothing, you cannot tell the difference between working and dead, and you will find out at the worst moment.
Cause three
Network, external drives, other applications — none are guaranteed at three in the morning.
Jobs that depend on something external need to check for it and exit cleanly when it is missing, rather than proceeding and producing something wrong.
Check for the drive before writing to it. Check for connectivity before fetching. Check that the application is running before scripting it. Where the requirement is absent, log why and stop.
The failure to avoid is a job that half-runs: writes some files, skips others, and leaves an inconsistent state that is harder to diagnose than a clean refusal.
Cause four
Six months later, the job that is failing is one you no longer understand.
Keep the job definition in the project it belongs to, in version control, with a short note: what it does, when it runs, what it depends on, how to install it, how to test it manually.
The manual-test instruction is the important one. Debugging a scheduled job you cannot run by hand is miserable; a documented one-line command that runs it immediately turns it into an ordinary problem.
Configuration living only in the scheduler's own storage is configuration that will be lost in the next migration.
The check
Ten minutes that catches the ones that died quietly.
List everything scheduled. For each, confirm it ran recently, confirm the output is still correct, and confirm you still want it.
There will usually be one that has been failing for weeks and one that is still faithfully doing something for a project that ended. Both are worth finding.
Put the review in the calendar. Automation that nobody audits is not infrastructure, it is a set of assumptions about the past.
1:1 · two hours