What three months of silence taught me about set-and-forget automation

A while ago I built an automation to research, write and publish content on a schedule, then I did the thing I warn clients about. I left it running and stopped looking. When I finally checked, the last piece it had published was three months old, and it had not crashed. It had quietly stopped doing the one job it existed to do, and nothing anywhere told me.

When I pulled it apart, there were three separate faults stacked on top of one another. A connector had renamed the function the automation was calling, so the publish step failed without a sound. A field name had drifted, so every image it tried to attach pointed at nothing. The research step was handing back text that could not be parsed cleanly. Any one of those would have been a five-minute fix if I had known, and the trouble was that none of them announced itself. The runs kept firing on schedule, burning through work, and the only visible symptom was an absence: no new posts.

Automation fails quietly, not loudly

This is the failure mode that matters, and it is not the dramatic one. We picture automation failing like a light bulb, on and then off, obvious at a glance. In practice it fails more like a slow puncture, losing pressure while everything still looks fine from the driver's seat.

New Relic's Observability Forecast found that teams with full-stack monitoring were far more likely to catch a high-impact outage within thirty minutes, and that better observability roughly halves the time it takes to notice something has gone wrong. The teams without it were still finding out from a customer. My own detection time, for a system I had built myself, was closer to three months, because I had wired up no way to notice at all.

Silent failure is common because most automations are chains, and a chain has plenty of quiet places to break. The failures are rarely clean crashes, more often slowdowns, timeouts and partial runs that finish and report success while doing nothing useful. If you are only watching for red error messages, this is exactly the kind of problem you will never see.

Why set-and-forget rots

Set-and-forget is an appealing idea because the entire point of automation is to stop thinking about a task. That is also exactly why it rots. The moment you stop looking, you lose the only feedback loop that would tell you the tool has drifted from the job you gave it.

Connectors update, APIs rename their fields, and upstream services rewrite their responses, none of which waits for your permission. An automation is not a machine you install once and own forever. It is a small standing relationship with half a dozen services that keep changing underneath it, and relationships that nobody tends will fall apart.

There is an uncomfortable irony in this for me. I spend my working week telling businesses that Ai and automation only pay off when they are governed, owned by someone, measured against a result, and checked on a cadence. I had built my own pipeline and given it none of that. The advice was sound; I had simply failed to take it on my own work, which is a very human way to learn a lesson properly.

The fix is governance you can wrap around any tool

The fix was governance wrapped around the tool I already had, applied as four simple habits. Any one of them would have turned a three-month gap into a three-day one.

  1. Watch for the output you expect and treat its absence as the alarm. A weekly job that has produced nothing for eight days should be raising its hand, even though technically nothing has errored.
  2. Measure the output the automation exists to produce, rather than the fact that it ran. My pipeline was firing on schedule the entire time, counting each run as a success when success should have meant a new post live with its image attached.
  3. Give every automation an owner and a review date. Anything that touches your business without a named person responsible will drift until it stops or does damage, and a recurring fifteen-minute check is cheap insurance against months of silence.
  4. Design the check before you design the automation. If the first thing you build is the way you will know it has stopped, you never end up discovering the gap by accident a quarter of a year later.

The lesson is simple enough to write on the wall above my desk, and I nearly have. Automation does not remove the work of paying attention, it moves that work from doing the task to watching the system. Set it up well and it will save you real hours every week. Leave it unwatched, and one day you will look up to find it has been quietly doing nothing for longer than you would care to admit.

Tommy Findlay

Chartered Engineer, MBA and Lean Six Sigma Black Belt. Founder of iS3, helping UK businesses adopt Ai with the discipline of an engineer.

How ready is your business for Ai?

Get your free readiness score in ten minutes.

Get Your Ai Readiness Score