Two silent failures on the same night, and every log said it was fine

What I expected

I had publishing jobs scheduled through the evening and one early in the morning, running on a laptop. The power settings said it would never sleep and the screen would never turn off on a timer.

So when nothing appeared overnight, I assumed one job had broken.

What actually happened

The machine’s own event log and the job logs for that night in August told a different story:

Due	Started	Result
20	20	ran, published nothing
23	never	missed
06	09	ran, published nothing

Every late start lined up with the laptop coming out of a low-power state: it woke at 20 and the job started a minute later; it woke at 09 and the job started seconds later. Around 03 it woke for about thirty seconds, too briefly for anything waiting to run.

That explained the times. It did not explain why the runs that did start published nothing. Their logs said there was nothing to publish, and they exited normally. No alert went out, because from the job’s point of view nothing had gone wrong. Meanwhile 13 items were sitting in the queue.

Why: two problems stacked on top of each other

The laptop was asleep. It does not have classic sleep at all, only what Windows calls Modern Standby: when the screen turns off, the system drops into a connected low-power state, much like a phone, and scheduled tasks wait. Sleep after “never” and screen off after “never” were already set. The option on a scheduled task that says “wake the computer to run this task” is ignored in this mode. Nothing I had configured was wrong; the machine just did not stay awake the way I assumed a plugged-in computer does.

The job believed its work was done. Before posting, a preparation step picks the next items from the queue. The item at the top was one it could not turn into the required format, so it skipped it. But it counted the attempt as one item prepared. With its quota “filled”, it stopped, and the posting step found nothing ready. Every run after that hit the same item first and made the same mistake.

Either problem alone would have been visible sooner. Together, one made the runs late and the other made the late runs empty, and both looked like a normal night.

What I changed

For the sleep problem, a short script now runs in the background from logon and tells Windows the system is in use, the way a video player does, without keeping the screen on. On battery it lets go. It needs no admin rights and no restart.

For the counting problem, the preparation step now counts an item only when it has actually prepared it, and logs a skipped item as skipped before moving on to the next one. The item that caused it was not deleted; it is now passed over automatically.

What this has to do with hiring someone

Neither problem was exotic, and a freelancer could have delivered either one. What made them expensive was that they were silent: no crash, no error, no alert, and a log line that read like good news.

That changes what I ask for. I want “where does this run” in the brief, because a hosted platform, a rented server and a laptop in the office fail in different ways; the trade-offs are in n8n, Make, Zapier or code. I want acceptance on real scheduled runs, including overnight, not on a button press, which is how the acceptance checklist for unattended work is built. And I want the definition of success to be something I can check from outside the job, such as “a post is live”, with an alert when a run is late, missing or produced nothing. If you are briefing a workflow automation build, ask for those in writing.