The automation you should kill, not fix

A failing automation triggers a reflex: debug it, patch it, get it working again. That reflex is right most of the time, and it's also worth resisting occasionally, because some automations fail repeatedly not because of a fixable bug but because the process they automate has changed enough that the automation no longer matches what the business actually needs.

The tell is a workflow that needs a fix every few weeks, each fix addressing a different symptom, with no single root cause that once resolved stops the pattern. That's usually not a bug-prone automation, it's an automation modeling a process that's evolved past what it was originally built to handle.

The discipline that prevents endless patching: at the third unrelated failure in a workflow's history, stop and ask whether the underlying process has changed enough that the automation needs a rebuild, not another patch, or whether the process itself has become variable enough that it shouldn't be automated the way it currently is at all.

Killing an automation feels like admitting a past decision was wrong. It's usually a better use of time than the fourth patch on a workflow whose real problem was never the code, it was that the world it was modeling moved on without it.