Six working days with no digest, and nothing said so
For six working days a scheduled routine of mine produced nothing, stayed visible in the list of scheduled jobs, and raised no error anywhere.
It read a task file every weekday morning, sorted it by priority and wrote a digest. The digest was the only thing anybody saw, so its absence was the only available signal, and nobody goes looking for a file that is not there.
I found out because I wanted the digest for an unrelated reason. Nothing had told me.
The registry entry outlived its own instruction file
The task file the routine read was intact. What had been deleted was the instruction file belonging to the scheduled job itself, while the scheduled entry stayed in place.
That combination turned out to be unrepairable with the tools available. The update command could not find the file it was supposed to change. The create command refused the identifier, because the registry entry still held it. The deleted file had lived in an application directory outside the folders I had access to, so it could be neither read nor removed from the command line. The only way out was deleting the job by hand through the interface and building a new one.
That is worth knowing before it happens, because the first instinct is to repair, and the repair path does not exist.
Four ways an unattended run fails without saying so
Over about 40 runs of two scheduled routines I collected four distinct failures. All four produce the same visible result.
| The failure | What it looks like from outside |
|---|---|
| The instruction file is deleted | The job is listed, runs on time, and produces nothing |
| A permission was never granted | The run stops at the first read, and an automatic run cannot answer a prompt |
| The application is closed | Nothing fires at all, and missed runs are made up later, so days vanish quietly |
| The registry entry survives its own file | The state above, and no tool repairs it |
Four failure modes, and not one of them raises an error. Each returns a clean empty result.
A routine producing nothing looks exactly like a routine with nothing to report.
From six months inside a B2B GTM organization with 36,000 accounts in its CRM.
Why an empty result is the hard case
An error is easy. Something in the chain says it failed, and somebody sees it.
All four of these fail as a success instead. The job ran, it ended, it produced no output, and no output is a valid state for a routine that looks for something and finds nothing. That is why a dashboard cannot solve it: every field the dashboard reads is still correct.
The second routine over that period produced 13 briefings between 19 June and 29 July. That is the useful shape of the fix, because a count of outputs with dates on it makes a gap visible. Nothing else in the setup would have.
A process that starts without anybody remembering it is the first thing anyone means by work running on its own. That condition holds only when something also records when the process last delivered, and in my own setup that second part was missing on both routines.
What to do instead
- Record the last successful run in the same place a person already looks for the result, rather than in a log nobody opens.
- Make the absence of a result an event. If yesterday produced nothing and the day before produced something, that difference is the alarm, and it is the only one available.
- Trigger every scheduled job manually once before trusting it. A permission that has never been granted will stop an unattended run, and the manual run is where that gets cleared.
- Expect to rebuild rather than repair. When the scheduled entry and its instructions disagree, the fast path is deleting and recreating it.
- Check the schedule against the definition, never against the label. In one case a confirmation screen showed a single day while two were configured, because the readable label could not parse a list.
The same failure with a marketing budget attached is a follow-up sequence that was switched on and never sent, and the reason it matters at all is visible in what happens to AI seats when no process starts in them.