Three outages, four alarm slots: what a nightly log drain teaches about laptop scheduling

The number worth staring at in the 2026-06-13 log is not the failure, it is the arithmetic. Every slot recorded the same pair of lines, a 04:55:00 start and a step2 timeout at 05:40:01 ^[7], which is 45 minutes and one second of wall clock ^[1] against a limit the writeup calls 40 minutes ^[6]. The pipeline listing, meanwhile, gives step2a a 1500-second timeout and step2b another 1500 ^[8], and 1500 seconds is 25 minutes, so the two digest stages between them are allowed 50 ^[3]. Three numbers for one limit. Whoever reads that log over coffee cannot say which stage died or how close it came, and that gap is the difference between tuning a timeout and guessing at one.

The failure also fed itself. The batch that blew the window was 28 hours of logs ^[6], four hours more than a day's worth ^[4], which means the queue was already carrying material some earlier run had not cleared. A retry slot then presents a larger job to the same ceiling. That is why the day failed uniformly rather than intermittently ^[5]. Re-firing is a remedy for interruption, and a job that is too big is not interrupted.

Sleep has the same shape seen from the other side. `caffeinate -s` holds only on AC power ^[3], so that layer is conditional on a fact about the room rather than about the script, and the extra slots exist to catch the mornings when the condition did not hold. Of the three remedies listed ^[9], only the step markers are unconditional. Markers are not exclusion, though. They record what has already been done, which makes a resumed run safe, but they do not make two processes take turns at one Git worktree. The 2026-06-10 conflict was a scheduled firing meeting a human at the keyboard ^[4], and the published remedy list contains no lock file or pid check ^[10].

A calendar trigger promises exactly one thing: that something starts at 04:55 ^[2]. That the run is alone, and that it ends, are properties the script has to supply itself, because launchd will happily start a second copy on top of the first and will wait forever on a subprocess that has stopped returning.

None of the three fixes is clever, and the author is straightforward that none of them came from a design document ^[15]. That is the case for writing them first rather than last. Redundant slots, a marker file, an explicit and logged timeout: each is small enough to have been in version one of any scheduled job, and the only reason they were not is that nothing had broken yet.