Posts

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. Run Scheduled Actually ran How late Result #3 Aug 12, 9:00 PM Aug 13, 9:49 AM ~12h 50m Failed (exit 1, DNS timeout) #22 Sep 27, 9:00 PM Sep 28, 9:23 AM ~12h 23m Succeeded #30 Oct 17, 9:00 PM Oct 19, 9:24 AM ~36h 24m Crashed (Debug Log #10) #34 Oct 26, 9:00 PM Oct 27, 7:24 AM ~10h 24m Succeeded #35 Oct 29, 9:00 PM Oct 29, 9:01 PM (on time) Not late Failed (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 mac...

Ten Debug Logs In: What the Series Actually Taught Me

Ten entries into a series that only exists because things kept breaking in ways worth writing down. Lined up together for the first time, they show a pattern I hadn't noticed while writing them one at a time. # Topic Views Likes Comments Type of mistake documented 1 Two analytics APIs, one near-identical error 50 0 0 Misread a second error as a retry of the first 2 A reader found a bug before I did 10 0 0 External feedback I hadn't caught myself 3 Trading-strategy backtest, three silent bugs 92 7 2 Code that runs without error isn't code that's correct 4 Free risk dashboard, curl.exe workaround 22 0 0 Blamed the wrong layer (API) for an unattended-execution bug 5 Blamed an API for being stale 32 0 1 Reported a rolling-average artifact as a real trend 6 Requested indexing on 17 pages 20 0 0 Hadn't checked the most basic metric (indexed or not) first 7 A phishing comment and a 4-deep reply thread 11 0 0 My own script only checked one reply level deep 8 A second burs...

The Post That Won't Stop Growing: Five Weeks of 'One Month In' Views, Tracked

Image
136 views, as of this check, on a post that had exactly 3 a week after it went up. Most posts on this blog hit most of their lifetime views in the first week and go flat. This one didn't, and I wanted the actual curve in front of me before guessing why. Post Views one week after publish Views now Still climbing? One Month In (Sep 22) ~3 136 Yes -- still adding views 5 weeks later Debug Log #3 (Sep 17) ~40 (fast initial spike) 92 Flattened weeks ago Debug Log #6 (Oct 2) ~20 20 Flat since week one What's different about the shape of this curve Debug Log #3 is the usual pattern on this blog: a fast spike from dev.to's own feed in the first few days, then flat. "One Month In" barely registered in its first week and has added views at almost every single checkpoint since -- 76, then 106, then 116, then 136 -- spread across five weeks instead of front-loaded into one. That's consistent with what's actually been driving it: the captd/kyisaiah47 comment thr...

One Day at Position #1. Then It Was Gone.

Position 1.0. For one day, one query, one impression, this blog's content sat at the literal top of a Google search result. I found out five days later, checking routine data, and I'm writing this up specifically to document that I'm not treating it as a milestone. Best single-day position recorded, in order Date 66.0 Aug 31 11.0 Aug 29 10.0 Sep 6 9.0 Sep 5 5.0 Sep 28 / Sep 30 4.0 Sep 29 3.0 Sep 3 1.0 Oct 16 What a single impression at position 1 actually means It means exactly one person's exact search, on exactly one day, happened to surface this blog first. It doesn't mean this blog now ranks first for anything in general -- Search Console's position number is calculated per-query, per-impression, and a single data point says nothing about whether the next person typing a similar search sees the same result in the same spot. The chart of best daily positions above trends downward over two months, which looks like steady improvement until you remember eac...

How Reliable Is the Wake-and-Catch-Up Mechanism, Actually? 4 Late Runs Out of 34, Counted.

Four times out of thirty-four scheduled publishes, this blog's machine was asleep or off at 9 PM and the post didn't go out until the computer woke up on its own schedule, sometimes the next morning. One of those four times is the reason this blog's very first post exists. One of them is Debug Log #10. The other two just quietly worked. Here's all four, side by side, which I'd never actually done before. Run Scheduled Actually ran How late Result #3 Aug 12, 9:00 PM Aug 13, 9:49 AM ~12h 50m Failed (exit 1, DNS timeout) #22 Sep 27, 9:00 PM Sep 28, 9:23 AM ~12h 23m Succeeded #30 Oct 17, 9:00 PM Oct 19, 9:24 AM ~36h 24m Crashed (Debug Log #10) #34 Oct 26, 9:00 PM Oct 27, 7:24 AM ~10h 24m Succeeded The actual reliability number 34 scheduled runs, 31 clean successes on or near schedule, 4 that needed the wake-and-catch-up mechanism, and of those 4, exactly 2 worked and 2 didn't. That's a 50% success rate specifically for the catch-up path -- not the pipeline ...

A Reader Did in 10 Minutes What I Said Was Impossible

Ten minutes. That's how long a reader says it actually took to do, by hand, the exact two things I'd just written a post declaring impossible without paying for them. Platform What I claimed What a reader actually did this morning Medium Closed to new API integrations since Jan 2025, no workaround medium.com/p/import takes the original URL and sets canonical automatically -- free, no token, no API. Dropped a markdown table silently; had to retype it as plain lines Hashnode API fully paywalled since June 2026 ($5/month Pro) Only the API is paywalled. The editor's publish dialog still has a free "original URL" field that sets canonical. Sign-in is a magic-link email, no Pro plan needed Where I went wrong "I Tried to Add Two More Cross-Post Platforms. Both Were Dead Ends" was accurate about the API specifically -- Medium really did close new integration tokens, Hashnode's API really did go paid-only. What I hadn't checked was whether the platfo...

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. Metric Value Scheduled time Oct 17, 9:00 PM Actual run time Oct 19, 9:24 AM (almost 36 hours late) Exit code 3221225786 (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 August All 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...