Automations that don't need babysitting: five habits
An automation is only useful if nobody has to watch it. The ones that end up watched — checked every morning, re-run by hand, quietly distrusted — almost always skipped the same few habits.
The promise of automating a business process is that people stop doing it. The failure mode is subtler than a crash: the automation runs, mostly, and someone starts checking it every morning just in case. A month later that person is the process again, only now with an extra system to distrust.
The difference between an automation people forget about and one they babysit is rarely the tool. It is a handful of engineering habits that are easy to skip when the first version works on the happy path.
1. Make every step safe to run twice
Networks time out, webhooks get delivered twice, and somebody will eventually press the retry button. If running a step again creates a second invoice, a second email or a second CRM contact, every retry becomes a risk and people stop retrying. The step is idempotent when repeating it has the same effect as doing it once.
- Give each unit of work a stable key — an order number, a message id — and refuse to process the same key twice
- Prefer “set the status to paid” over “add a payment” where the target system allows it
- When calling an API that supports idempotency keys, always send one
2. Retry what is temporary, stop on what is not
A timeout or a rate limit is worth retrying, with a pause that grows each time. A validation error is not: the request is wrong and will be wrong again. Retrying everything turns a single bad record into an endless loop and a pile of alerts; retrying nothing turns every network blip into a manual task. The rule is simple, but it has to be written down per integration, because every API reports errors differently.
3. Failure goes somewhere a person will see it
Logs nobody reads are not monitoring. When a step gives up, the failure should land where the team already looks — a chat channel, a queue in the tool they work in, an email to an owner — with enough context to act without opening a terminal: what was being processed, what went wrong, and a link to retry it.
Just as important is knowing when nothing happened at all. A nightly sync that silently stopped running produces no errors. A simple check that alerts when the expected run did not complete catches the failures that error alerts never will.
4. Keep a record of what the automation did
Sooner or later someone asks why a customer received two emails, or why a deal moved stages on its own. If the only answer is to read code and guess, trust in the automation erodes quickly. An audit trail — what ran, when, on which record, with what result — turns those questions into a two-minute lookup and makes the system defensible.
5. Put a human checkpoint where mistakes are expensive
Not every step should be automatic. Sending money, deleting data and contacting customers at scale are worth a single approval click, at least until the automation has a track record. The approval step costs seconds; an unreviewed mass email to the wrong segment costs a week of apologies.
- Reversible and low-stakes: fully automatic
- Reversible but visible to customers: automatic with an easy undo
- Irreversible or financial: prepared automatically, confirmed by a person
Choosing the tool comes after
None of this depends on whether the automation is built in a no-code platform, a workflow engine or a few hundred lines of code. Each of them can be made reliable or fragile. What changes is how much of the reliability you get for free and how much you have to build. That trade-off is worth making deliberately, after the five questions above have answers.