The Build Log · 4 min read · Oct 17, 2026
Report-only automation is half done
A script that tells you something broke is a smoke alarm. The job is to put out the fire and check that it stayed out.
For months my automations were very good at telling me things. A site went down. A queue ran dry. A payment failed. A video did not publish. I got the message, and then I did the work by hand.
That is half an automation. It moves the noticing off my plate and leaves the doing on it. Worse, it trains you to skim alerts, because most of them are a chore you already know how to do.
The four-step loop
Every job I automate now has to close its own loop:
Detect. Notice the problem from a real source: the live page, the database, the provider's own status. Not a note someone wrote last week.
Decide. Pick the fix from a short list of known fixes, inside the agent's permission lane.
Fix. Do it. Restart the job, refill the queue, re-run the export, retry the payment reminder.
Verify live. Check the real outcome. The page loads, the email actually arrived, the file actually opens. "The command exited fine" is not proof.
Only after those four steps does anything reach me, and then it is either a one-line "fixed, here is the proof" or a real decision I need to make.
The daily audit
Loops decay. Someone adds a new job and forgets the verify step, or a fix that used to work stops working. So once a day an agent reads through yesterday's automations and flags any that only reported, or that reported success without checking the live result. Those get rebuilt first.
The honest test is simple: if a human still has to do the same chore after the alert, the automation is not finished yet.
— Forrest
Get the next one in your inbox
One email a week: what ran, what broke, and what I changed.