My Automations Didn't Crash. They Just Stopped Talking.
· 5 min read · by Michael Kaminski
Behind the Build, Vol. 6: the daily-article robot quietly skipped four days without erroring once. A look at the fleet of small agents I now run across a portfolio site, a trading account, a resale business, and a spend audit — and why silence is the failure mode nobody instruments for.
Nothing new appeared on this site on the 25th, the 26th, or the 27th. The automation responsible for publishing here did not throw a single error during that stretch. No alert, no red build, no stack trace. It just… went quiet.
The twist, which turned up only later: it had been running the entire time. Every one of those days produced an article. They were stranded in branches that never merged — which, from outside, is indistinguishable from having produced nothing at all.
That's Vol. 6, then. Not a feature I shipped — a failure mode I found.
What "the codebase" actually looks like now
A year ago, "what I'm working on" meant one repo at a time. Now it's closer to a fleet of small, unrelated automations that happen to share an operator:
- A portfolio site that publishes a daily writing series — the thing you're reading, and the thing that broke.
- A Products page, shipped on the 25th, cataloguing desktop tools that had been sitting in public repos with no front door: a macOS system monitor with a desktop HUD, a touchscreen driver, an ambient context-capture daemon. The code already existed. The discoverability didn't.
- A brokerage read-only reporter that pulls positions across several accounts each morning and reasons about margin eligibility before anything gets sized.
- A recurring-spend auditor that scrapes every subscription and recurring charge, hunts for cheaper equivalents, and re-checks each open decision weeks later so "I'll deal with it" has an expiry date.
- A live-commerce assistant that works the chat during a resale livestream, and a separate one that posts the go-live announcements.
- A lead-import pipeline that pulls a public contractor licensing dataset, scores it for buyer intent, and pushes it into a database behind an outreach app.
None of these are related. A trading account and a livestream chat bot share exactly zero domain logic. But structurally they're the same animal: capture some context, impose a schema on it, make it re-runnable, and let it run without me. That last clause is doing an enormous amount of unearned work.
The failure mode is silence, not errors
Every one of these has decent error handling. What none of them had was a check on the thing that actually went wrong here, which is absence. The article robot didn't fail loudly — it fired, wrote, and left the result somewhere the site couldn't see, which looks identical from the outside to never having fired at all: a quiet day.
Traditional monitoring is built around events. Something happened, and the something was bad. But an automation whose whole job is to produce something on a schedule has an inverted signature: the bad state is the lack of an event. If your alerting only fires on errors, a job that silently stops is indistinguishable from a job that ran perfectly and had nothing to do.
The fix isn't clever. It's a freshness check — assert that the newest item is dated today, and treat stagnation itself as the bug. That's now written down as a rule for this repo in plain language: never skip a run, and if you can't publish today, publish to the next open date rather than quietly doing nothing. Same idea as a dead-man's switch, which fire alarms and pacemakers figured out decades before software did.
Why this gets worse as the fleet grows
One automation you notice. Two you probably notice. By the time you're running a dozen small agents across unrelated domains, you have no ambient sense of which ones are alive, because you're not looking at any of them — that was the entire point of building them. The value of automation is that you stop paying attention, and the cost of automation is that you stop paying attention.
Which reframes what "operating a fleet" actually requires. Not more agents. A cheap, boring, per-agent answer to one question: when did this last successfully produce something, and is that recent enough? Everything else — the model, the prompt, the clever tool use — is downstream of a heartbeat.
The lesson
I spend a lot of time on the seam between finance and engineering, and this is a very finance observation dressed in engineering clothes: the absence of a transaction is data. A reconciliation that comes back empty isn't a clean month — it's an unanswered question. Same with an agent that has nothing to report. Both need someone to notice the quiet.
Three silent days is a cheap way to learn that. Cheaper than the version where the thing going quiet is a trading report or a spend audit.
Next time in Behind the Build: whatever breaks next. Historically, this has been a reliable pipeline.