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...