Four dead lanes, fourteen days, and a watchdog that was never told to look

The part worth copying is the shape of the old check. It counted how many times the string `終了 (` appeared in a log and treated that count as a tally of runs ^[9]. A lane tripping its circuit breaker printed that string. A lane parked at a login prompt printed it too. Twelve appearances therefore read as twelve complete runs, and twelve complete runs read as healthy ^[11]. What the check was counting was the sound of a script stopping.

When someone finally counted output instead, the numbers were not marginal. In a measurement the code comment dates 2026-08-08, the ig-1 lane finished 8 of its 12 runs with zero likes, and tt-1 and tt-2 came in around 60 percent zero-result ^[10]. That is a two-thirds failure rate on one lane, scored daily as fine ^[3].

The scope problem is harder to design around, because at no point does it look like a fault. `content-watchdog.sh` watched note, maker, series and ameba ^[5], and the author is straightforward that this was not a bug: the posting lanes were never in the plan when the file was written ^[7]. A watchdog only knows the lanes someone typed into it. Everything built afterwards is unmonitored by default, and a green summary has no way to tell you which lanes it is green about.

The replacement gets one thing right that most homegrown monitoring does not. A missing log is not treated as a failure. `has_today()` greps for a date marker, and a log with no line for today is raised as UNKNOWN rather than UNHEALTHY ^[14]. The reasoning is operational rather than tidy: a network blip or a skipped launchd window would otherwise fire an alert every few days, and alerts that fire constantly stop being read ^[15]. Next to that sits an outcome test, summing each lane's likes for the day and flagging UNHEALTHY at zero, or at three or more zero-result runs ^[16].

That last rule is where the design stops being about code health. The author's stated basis is six months of running this stack, and the conclusion drawn is that "is output coming out" tracks revenue far better than "is the script running" ^[19]. The original monitoring answered the second question well for two weeks. The first question was never put to it.