Why the Devlog Automation Sat Broken for Nearly a Month

With no logs at all, there was no way to tell "running" apart from "dead"

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

This blog's devlog gets wrapped up automatically every night. If I'd written a draft in conversation that day, it gets converted and logged; if not, one skip line gets logged instead. I recently had reason to look at this pipeline, and found the log had been completely empty since July 24th.

What happened

The last line in the automation log (.automation.log) was dated 2026-07-24. After that, all the way through August 22nd — nearly a month — not even a single skip line had been recorded.

I wondered if the automation had simply stopped running, so I opened the execution log (cron_output.log). It was packed with traces of runs, every single night.

Checking the date, summarizing the draft when one existed, wiring up cross-links — a full night's worth of work was recorded there, every night. The work was happening. Nothing was just failing to be saved.

Why nobody noticed

Reading through the execution log, the cause was the same every night: the run got stuck waiting for a file-write permission approval that never came.

A "workspace has not been trusted" warning was printed on every single run. The draft would be neatly prepared, and then the very last step — writing the file — would sit blocked on approval until the session simply ended. This pattern repeated for nearly a month.

The problem was that this happened to block the exact step that would have left a log trail. On skip days, not even the skip line could be written. So the log itself couldn't distinguish "the automation stopped" from "there was quietly nothing to write."

Since this is unattended automation, nobody is watching a screen every night either. As a result, this gap had no way of surfacing until someone happened to open the log file by chance.

The real cause

The cause was a trust setting. This headless automation session needs its working folder to be trusted before it can write files, but the key for that trust setting was scoped one level too high — to the parent directory that holds all the projects, not to this blog's own folder.

Looked at from this blog folder alone, it was being treated as "a brand-new workspace that has never gone through interactive trust approval." Ten allow-rules already existed in the settings file, but the scope those rules were keyed to was being ignored entirely.

Unattended overnight automation has nobody around to answer an interactive approval prompt. One trust setting scoped to the wrong level was quietly disarming the run at exactly the same point, every single night.

One interesting detail — a ghost completion record

While retracing this gap, I found one unusual line. At 12:41 PM on August 22nd, a "weekly: complete" line had been logged, but no actual output file existed for that timestamp.

Later that same day, at 4 PM, there was a separate manual run recorded, and this one did produce the actual file correctly. What caused the earlier 12:41 PM entry to log "complete" with nothing actually written couldn't be pinned down.

It landed in the middle of the permission trouble, so the best guess is that some part of the write sequence succeeded while another part failed. Either way, this one line carried its own separate lesson: a log line that says "complete" isn't fully trustworthy on its own. Without cross-checking the log against the actual output file, this ghost entry would have gone unnoticed.

How it was fixed

Rescoping the trust setting to this blog folder specifically fixed it immediately, starting that same night. No complicated remediation was needed.

The real problem wasn't how to fix it. It was that the problem had gone unnoticed for nearly a month.

The general lesson

What this confirmed, once again, is that "no logs" is itself a signal in unattended automation. But treating that signal as a signal requires the system to be designed, from the start, to distinguish silence from successful inaction.

This pipeline was built to log one line even on skip days. That design is exactly what made it possible to eventually notice that "logs stopped accumulating entirely" was itself out of normal range.

If that skip-log mechanism hadn't existed, it would have been easy to mistake the gap for "must have just been a quiet month with no drafts." Whether it's a CI/CD pipeline, a cron job, or any background batch process, this same gap can appear whenever the absence of output doesn't itself trigger an alert.

I relearned that when designing anything meant to run unattended, you need at least one mechanism that lets a person tell apart "quiet because it's working fine" from "quiet because it's dead." A heartbeat, a skip log — the specific mechanism doesn't matter. What matters is never letting a total absence of signal get mistaken for normal.