Building the audit that watches the automations.
For months my personal OS ran on faith. A handful of scheduled jobs fired overnight — capture, ingest, digest — and each morning a brief appeared. If the brief showed up, I assumed everything underneath it had worked. That assumption was the bug.
Background jobs fail quietly. A scheduler boots a task out of its queue, an environment variable goes stale, a permission lapses after an update — and nothing announces it. The brief still arrives, just thinner, and you don't notice until a week of captures has evaporated.
Two layers, two questions
So I built an audit with two layers, each answering a different question. The first is a daily heartbeat: did every job actually run within its expected window? It reads the live state of each scheduled task and compares last-run timestamps against each job's cadence. The second is a weekly governance pass: do the system's own documents still agree with each other?
The goal was never zero failures. It was: never fail silently.
The design rule that fell out of it is the one I keep coming back to — silence means healthy, noise means act. A green dashboard nobody reads is worse than no dashboard; a system that only speaks when something is wrong earns its alerts. The daily heartbeat is the single deliberate exception: it sends one positive note a day, because a channel that has been silent for a week is indistinguishable from a channel that is broken.
The blind spot it caught
The satisfying part: on its second run, the audit flagged that the watchdog meant to guard the other jobs wasn't itself being guarded. The thing watching everything had no one watching it. One line of config closed the loop — and the system had, in effect, found its own gap.
That is the whole point of building tools you then read back slowly. You don't just get the automation; you get a clearer picture of where it can break. The audit didn't just check the work. It taught me what I'd forgotten to check.
← Back to The Journal