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 as a whole, which is running at 31 successes and only 1 unrecovered failure out of 34, or about 97%. Both numbers are true at once, and they answer different questions: "does this blog publish reliably" (yes, overwhelmingly) and "can I trust the catch-up mechanism specifically if the computer misses its window" (closer to a coin flip).
Why I never looked at this as one dataset before
Run #3's failure got written up back in August as the discovery of the DNS-after-wake problem. Run #30's crash got written up three weeks ago as Debug Log #10. Runs #22 and #34 never got mentioned anywhere, because they just worked and there was nothing to report. That's a selection effect worth naming: every post about this pipeline's reliability so far has been about a failure, because successes don't generate anything to write about. Lining up all four late runs together, instead of only the two that became posts, is the first time the denominator has been visible instead of just the numerators that went wrong.
What I'm not doing about the 50%
Two data points isn't enough to fix a mechanism, it's barely enough to notice the split exists. The honest move is tracking it, not patching something based on a coin flip's worth of evidence. If a fifth late run happens and it also fails, that's a real pattern worth acting on. Right now it's a number worth knowing, not a bug worth chasing.
Top comments (0)