Build1 distinct publisher3 min readUpdated
One shell flag turned an upstream timeout into a fatal exit and blanked a status bar for seven days. The repair, both times, was to keep printing something, even when that something is n/a.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The exit code was doing exactly what it was told. In his dev.to writeup, the author has launchd firing the script every 30 minutes [8], so seven days of `exit 1` is on the order of 336 scheduled runs [3], every one of them correctly reporting failure to the scheduler and to nobody else. A status bar has no opinion about exit codes; it renders what the process prints, and the process printed nothing [4]. The status went to the only consumer that could not act on it.
The two failures are worth measuring against each other, because they were caught by different mechanisms. The overcount was $234 against a real $48 [1], about 4.9x [1], which lands inside the 4-6x band the double-summing bug produced [2] and amounts to $186 of spend that never happened [2]. That kind of wrong is self-reporting: the number was implausible enough to send him to a second counter. Silence has no implausibility. It ran a full week and was surfaced by two 5-hour blocks crossing critical [5], which is to say it was surfaced by the thing the monitor existed to prevent.
What the rewrite changes is which consumer the script owes an answer to. The scheduler always gets zero, and the screen gets an explicit `n/a` [6], because "no data" and "healthy" have to look different on the surface a human glances at [14]. That is a property of the whole call graph rather than one flag: `set -u` stays and only `-e` comes out [10], and a failed ccusage read leaves the token variable as an empty string and keeps going rather than leaving it unset [11]. Three separate degradations are handled in 212 lines of bash wrapped around a Python heredoc [9] [11], including the first-run case where the log file does not exist yet, which killed the earlier version on an exception [16].
The accuracy story deserves less credit than the availability story. A 2.3% source-to-source gap [3] is roughly $1.10 on a $48 week [4], and it describes agreement between his own JSONL log and ccusage [11], both of which read the same machine. The 4-6x error was only ever visible because one of those two counters disagreed with the other [1] [2]. The invoice is the third source, and it has not been entered into evidence here.
Fail-open buys distinguishability, not attention. The author's stated requirement is that the script never goes quiet rather than that it be accurate [15], and on his own account he sat in front of a blank bar for a week [4]. A dot reading `n/a` occupies the same pixels the blank did, and nothing in the structure he describes treats a hundredth consecutive `n/a` differently from the first.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author's monitor reported a 7-day spend of $234 while ccusage daily put the real number at $48.
The source-to-source gap is now 2.3%.
After the script was hardened with set -euo pipefail, a single ccusage timeout made the whole thing exit 1 and the author's status bar sat blank for a week.
The fix in both cases was the same design decision: fail open, print a black-dot n/a, and exit 0.
The script's header keeps set -u and explicitly drops -e as a fail-open policy.
The cause was double-summing cumulative log lines, producing a 4-6x overcount.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-reported account with real code excerpts but no verifiable numbers
The mechanism claims are well evidenced for their type: the article quotes the script header, the fail_open() helper, and the three call sites with line numbers, and diagrams the ccusage/JSONL/Python data path, so a reader can judge the design directly. Everything quantitative is one developer's unaudited recollection — $234 vs $48, the 4-6x overcount band, the 2.3% residual gap, the seven-day blackout, the two missed critical blocks — with no repository, log sample, or second publisher to corroborate. The $3,000/week cost ceiling is asserted with no supporting data at all.
One developer's machine
Adoption evidence is limited to the author's own environment: the script is genuinely deployed and scheduled (launchd every 30 minutes, rendered into a status bar and terminal dashboard) and has produced observable operational history including a week-long failure, which is more than a proof of concept. But there is no released artifact, no download or star count, no other user, and no organizational rollout, so this is n=1 personal tooling built on top of a third-party counter (ccusage).
Sound narrow lesson, oversold as a general principle
The core finding — fail-closed monitoring renders silence, and silence is indistinguishable from health — is modestly stated and matches the evidence. The framing around it runs ahead of it: the absolute rule that a monitor needs 'never going quiet' rather than accuracy is asserted from a single incident even though the same post opens with a 4.9x accuracy failure, the personal-revenue arc and 'autoimmune system' language add promotional lift, and the $3,000-per-week ceiling is dramatic relative to a measured $48 week. Positive but small: the engineering substance is real, the generalization and the money figures are not backed.
Self-published personal-brand content tied to a side-business narrative
The post is a first-person dev.to article whose author interleaves the technical content with a monetization arc (income rising to ¥1.2M/month, six months building an autonomous Claude Code environment, 'mass-producing personal projects as a side business'). That creates a clear incentive to present the environment as a validated productivity system and to dramatize cost risk, and the author is also the sole source of every number in the piece. Offsetting factors: the piece foregrounds the author's own two failures rather than a success story, quotes real code, and sells no product, license, or paid tool in the supplied text.
Confident on the mechanism, weak on everything measurable
Confidence is asymmetric. The design claims — dropping -e, the fail_open() contract, exit 0, the three guarded layers, the aggregation windows and output modes — are quoted from the artifact and can be assessed as written, so they are high-confidence descriptions of one script. The incident narrative and all figures are single-source, self-reported, and unverifiable, and adoption is n=1, so confidence in the generalizable and quantitative parts of the story is low. Averaged across the cluster this sits below the midpoint.
build
Config rot has a latency bill: a 70-line weekly audit for agent environments1 distinct publisher
build
The 46GB Leak Your RSS Alert Cannot See: macOS Compressed Memory Breaks Threshold Monitoring1 distinct publisher
build
Exit 0 is not a health check: three weeks of macOS backups that copied nothing1 distinct publisher
build
26 launchd jobs, one log directory: how scheduled automation rots quietly1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026