The failure mode is silence: what a weekly per-line output report catches that uptime does not

The interesting thing about the script described in the dev.to post is that it does not watch the jobs at all. It counts files in each line's output directory, then reads a revenue log (`revenue.jsonl`) and a line-definition file to decide what those counts mean ^[7]. Nothing in that design asks a process whether it is alive. A dead job has no opinion to offer, which is exactly why the count is the signal: absence shows up as a number going down.

There are two failures in the scheme and they are not symmetric. Zero files means the line stopped ^[3]. Files above zero with revenue at zero means the line is running and losing money, and that is the case the state file tracks, as a count of consecutive zero-revenue weeks ^[8]. Only the second one bills you while it happens: a single prompt run is a few yen, but hundreds of files a week across fourteen lines add up, and the author's point is that without per-line numbers there is no cost-cutting decision to make ^[5]. Five of the lines named in the post already account for at least 189 files a week ^[13], so neither the spend nor the exposure is spread evenly across the fourteen.

A weekly report also has a weekly worst case. At 14 files a week, a stopped ASMR line could swallow a full week of output before Monday's report mentions it, roughly 14 files gone ^[14]. The author's actual catch was faster: the first report is dated 2026-07-03 and the flag appears on 2026-07-06, three days later ^[2][3]. That sits oddly against the stated schedule, which is `launchd` firing twice on Mondays, at 8:20 and 13:20 ^[6]. Either the early cadence was denser than weekly or one of those reports was not a scheduled run. It matters because the three-day catch is the number readers will remember, and the design only guarantees seven.

The refusal to stop anything automatically is the load-bearing constraint. A flagged job is killed only when the operator cannot answer what it is for, who benefits, how much it earns, and when to cut it, and the script itself never intervenes ^[9]. The stated reason is that an automatic stop cannot be audited afterwards and a false positive could take out the top earner ^[10]. The same logic cuts back at the detector: in a file count, a silently dead line and a deliberately paused one look identical ^[7], so the report can only ever hand over a fact and a date.

The habit argument is the part that generalises past one Mac. The author says a weekly spreadsheet never survived as a habit, so the report is generated and dropped where he will see it with nothing to fill in ^[11][12]. Everything here rests on one operator's account of his own setup, including the ¥1.2M a month ^[1]. The transferable piece is not the shell script. It is choosing the unit (a line), the metric (files out and money in), and a schedule that arrives whether or not anyone remembers to look.