Debug Log #11: The Reliability Stat From 4 Days Ago Was Already Wrong

Four days ago this blog published a post with a specific statistic in the title: 4 late runs out of 34, 2 of them successful. That post was still fresh when a fifth failure showed up -- and this one breaks the pattern the stat was built on, because it wasn't even late.

RunScheduledActually ranHow lateResult
#3Aug 12, 9:00 PMAug 13, 9:49 AM~12h 50mFailed (exit 1, DNS timeout)
#22Sep 27, 9:00 PMSep 28, 9:23 AM~12h 23mSucceeded
#30Oct 17, 9:00 PMOct 19, 9:24 AM~36h 24mCrashed (Debug Log #10)
#34Oct 26, 9:00 PMOct 27, 7:24 AM~10h 24mSucceeded
#35Oct 29, 9:00 PMOct 29, 9:01 PM (on time)Not lateFailed (exit 1, DNS timeout)

What's different about run #35

Every previous failure in this table happened because the machine was asleep past 9 PM and the catch-up mechanism fired late, sometimes many hours late. Run #35 fired exactly on schedule, at 9:01 PM, one minute after the trigger -- and still hit the DNS timeout that's supposed to only happen when a machine is waking from sleep. The wait loop ran its full five minutes, never got a DNS response, and exited cleanly with code 1, exactly as designed. The design isn't broken. The assumption that this failure mode is tied to lateness specifically -- which the "4 late runs" post stated as fact four days ago -- was wrong.

The corrected numbers

39 scheduled runs total, 34 clean successes, 5 that hit a real problem. Of those 5, 2 were crashes or DNS failures while arriving late, 2 were late arrivals that worked fine, and 1 -- this one -- was a DNS failure with no lateness involved at all. The headline stat from four days ago undercounted by exactly one, and understated the failure mode's reach by treating "late" as a precondition it isn't.

Why I'm not retroactively editing that post

The instinct is to go fix the number in place so it's not sitting there wrong. I'm leaving it as published and writing this instead, for the same reason Debug Log #9 didn't get folded backward into Debug Log #8: a correction dated after the fact is the more honest record than a quietly adjusted one. Readers who saw "4 out of 34" should also be able to see that it became "5 out of 39" four days later, not just a cleaner number that replaced it without a trace.

What this actually means for the DNS wait loop

Five minutes of retries isn't catching every real case of slow network recovery, on-time trigger or not. That's a genuine, now twice-confirmed limitation, not a one-off. Whether to extend the wait window, add a second retry pass, or leave it as a known, occasional, self-recovering failure is a judgment call about how much engineering a ~9% failure rate on a personal publishing script actually deserves -- and not one I'm making unilaterally in this post.

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

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

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