Debug Log #10: A Post Didn't Publish On Schedule, and I Can't Fully Explain Why

One post out of thirty didn't go out on schedule, and the exit code it left behind means "something killed this process," not "something went wrong inside it." I found this by accident, checking in on the blog two days after it should have published. Here's what I can establish and what I genuinely can't.

MetricValue
Scheduled timeOct 17, 9:00 PM
Actual run timeOct 19, 9:24 AM (almost 36 hours late)
Exit code3221225786 (a control-C-style forced termination)
Post created on Blogger?No -- confirmed via API, no draft, live, or scheduled version existed
Other 29 scheduled runs since AugustAll exit code 0

What I can confirm

The task didn't fire at 9 PM on the 17th, which almost certainly means the machine was asleep or off at that moment -- the same root cause this blog's very first scheduled-task post documented back in August. The "wake and catch up" setting did its job eventually, just thirty-six hours later than intended, when the machine was next available. At that point the process started and was killed almost immediately -- no post ever reached Blogger, and the log file has no entry for it at all, meaning the failure happened before the script got far enough to write anything.

What I can't confirm

Windows' Task Scheduler operational event log is disabled on this machine, so there's no record of what actually sent the kill signal. My best guess is that the catch-up run collided with something else happening on the machine right around login time the next morning -- but a guess isn't a diagnosis, and I'm not going to write this up as solved when it isn't. Enabling that log is the obvious next step if this happens again, and I haven't done it yet, which is itself worth stating plainly rather than quietly fixing in the background.

Why the other 29 runs are the actually reassuring part

It would be easy to read "a post didn't publish" as evidence the whole pipeline is fragile. Checking every other run this project has made since August says otherwise -- 29 scheduled publishes, 29 clean exits. One late, killed run in 29 is a single bad night, not a pattern, and treating it as a pattern would be the same mistake Debug Log #5 already caught this project making with a different metric.

What happened to the actual post

I found the gap, reran the script by hand, and it published cleanly on the first retry -- so the content itself was never the problem, only that one scheduled run. The real fix, enabling proper logging, is still open.

Related reading

Comments

Post a Comment

Popular posts from this blog

My OAuth Tokens Kept Expiring Every 7 Days, and the Reason Was a Dropdown Labeled 'Testing'

Three weeks into running my publishing pipeline on autopilot, it just stopped. Not with a crash -- with the exact same error I'd already spent a week debugging and fixing once before: invalid_grant: Token has been expired or revoked . Same message, same script, same working setup. I assumed I'd broken my own fix. I hadn't. This was a completely different bug wearing the same disguise, and it had been sitting there from day one, counting down. The first time I saw this error The first time invalid_grant showed up, I'd just spent days chasing a silent scheduled-publish failure that turned out to be a PowerShell file encoding bug. Once that was fixed and confirmed working for a couple of runs, I filed the OAuth error away as "collateral damage from the encoding mess" and moved on. When it came back three weeks later, with the encoding fix still verified working, that theory stopped holding up. My setup uses the OAuth installed-app flow: run the script once,...
Read more

How I Wired Up Fully-Automated Cross-Posting Between Blogger and dev.to (With Working Code)

The last two posts on this blog went out through a pipeline I built specifically so I wouldn't have to manually copy-paste content between platforms. Here's the actual setup, in case you're trying to do the same thing. The goal One command, two platforms: publish to Blogger (where this blog actually lives) and have it show up on dev.to at the same time, without dev.to's copy counting against the original for search ranking purposes. Piece 1: Blogger, via its own API Blogger still has a working API (v3), authenticated through standard OAuth — no service-account keys needed, which matters if your Google Cloud project has an org policy blocking those (mine did). A one-time browser login gets you a refresh token; after that, a script can call posts().insert() or posts().update() and posts().publish() without touching a browser again. Piece 2: dev.to, via its API dev.to exposes a simple REST API gated by a personal API key (generate one under Settings → Extension...
Read more

I Compared the Free Tiers of Google Flow, Kling AI, and Hailuo So You Don't Have To

In my last post , I mentioned pivoting away from AI-generated video after digging into the free tiers of the big three tools. Here's the actual digging — what each one gives you for free, and where the fine print gets in the way. I'm not affiliated with any of these tools. I just wanted a straight answer to "can I use this for a monetized channel without paying," and it took longer to find than it should have. The short version Tool Free credits Renewal Max clip length (free) Watermark Commercial use on free tier Google Flow (Veo 3.1) ~50 Daily 8 seconds "Made with Veo" visible Unclear — see below Kling AI ~66 Daily ~5 seconds per generation Visible Explicitly excluded Hailuo / MiniMax 200 One-time (new account bonus) ~6 seconds (768p) Visible Explicitly excluded Google Flow (Veo 3.1) Flow bundles Veo 3.1 (video), an image model, and a music model into one workspace. The free allotment is roughly 50 credits a day, n...
Read more