Every setting was correct and the job died anyway: the assertion nobody writes

The control that was missing is one line of arithmetic, and it has to run before the first action fires: sum the caps, multiply by the maximum delay, add the maximum startup jitter, and refuse to start if the total exceeds the supervisor's timeout. On the numbers in the post that check fails loudly. The caps total 101 actions ^[4], the delay range tops out at 60 seconds ^[5], and jitter can add 900 ^[7], so the worst-case run needs 6,960 seconds against a 2,400-second window ^[2]. Off by a factor of nearly three.

The author computed 4,040 seconds using the 40-second mean ^[6]. For a deadline the mean is the wrong statistic; what matters is whether the unluckiest draw fits. It matters in the other direction too. At the 20-second floor, 101 actions need only 2,020 seconds and do fit, with 380 seconds left for jitter and for the page loads themselves ^[3]. A morning with low delay draws and a small jitter offset therefore finishes, which is presumably why the settings survived earlier runs and why the failure reads as intermittent rather than as arithmetic.

Invert the same assertion and it sizes the cap instead of testing it. With 900 seconds of jitter reserved and 60-second delays, a 2,400-second slot funds 25 actions ^[4]; at the mean it funds 37 ^[1]. The configured 101 is four times the safe figure, so a slightly larger timeout does not rescue it. Nor does the friendliest reading: 1,500 seconds of usable time split across 101 actions is 14.9 seconds each, below the configured 20-second minimum ^[6].

One more piece of arithmetic in the post is worth checking, because it hides half the overrun. It reports 4,940 seconds as 1.7 times the window ^[9]. Divide it out and 4,940 over 2,400 is 2.06; 1.7 is what you get from 4,040 over 2,400, with the jitter dropped somewhere between the sum and the ratio ^[5].

The reason this cost two weeks rather than one morning is that the failure does not reset. Cleanup lives in a finally block ^[11], and SIGKILL is delivered by the kernel with no handler run at all, so ctx.close() never executes and the Chromium process is left behind ^[10]. Every dead run adds to the pile. By August 5, according to the author's own measurements, the machine was carrying 1,527 accumulated processes, 395 of them node, with idle CPU at 18% and load average at 24.6 ^[13]. The misconfigured job was one of more than 160 registered on that box ^[15], and the ones that visibly broke had innocent numbers in their own config.

That is the case for putting the check where config is loaded rather than trusting review to catch it. The number that kills the job lives in a launchd plist as BROWSER_SLOT_TIMEOUT_SEC and the numbers that spend it live in Python ^[8], and neither file contains a wrong value.