What separates an automation that lasts from one that breaks

Two builds can do the same job and look identical on the canvas. One runs for years. The other quietly stops being trusted around week six. The difference is six things, and none of them show up in a demo.

Notes on the boring parts · 9 minute read

Almost any automation works on the day it is built. You run it with clean test data, the record appears where it should, everyone agrees it is clever.

What separates the ones still running a year later is not cleverness. It is a short list of decisions made about failure — decisions that cost very little at build time and are expensive to retrofit once real data is flowing through.

If you are paying someone to build one, these are the things worth asking about. If you are building it yourself, these are the things worth doing before you turn it on.

1. It knows the difference between failed and unknown

Most workflows are built with two outcomes in mind: it worked, or it errored. Real systems have a third, and it is the one that causes damage — we do not know.

A request times out. The call may have landed. It may not. The response never came back, so from the workflow's point of view those two very different worlds are indistinguishable.

Treat unknown as failure and retry, and you risk doing the thing twice — charging a card, sending an email, creating a record. Treat it as success and move on, and you silently lose work.

A build that lasts decides deliberately which way to fail, and makes retrying safe by sending an idempotency key so the far end can recognise a repeat.

A confident wrong answer is worse than no answer.

2. Bad records go somewhere a person can see

Every intake eventually receives something malformed — a blank required field, a date in an unexpected format, a name in the email column.

The convenient thing is to filter it out. The workflow keeps reporting success, the dashboard stays green, and the records are simply gone. Nobody notices for weeks, and when they do, the data needed to reconstruct what happened is not there either.

A build that lasts routes anything it cannot process to a queue with the reason attached. It costs one extra step. It is the difference between a system that occasionally needs attention and a system that quietly lies to you.

3. It only retries things that can succeed

Retry logic is often a single toggle: on, with three attempts. That is better than nothing and worse than it looks.

A 429 or a 503 means try me later — the far end is busy or briefly unwell, and the same request may well work in ten seconds. A 400 means this request is wrong, and it will be exactly as wrong on the tenth attempt.

Retrying everything burns rate limit you may need, delays the alert that something is broken, and buries a bug you needed to see today rather than next month.

4. Somebody would find out if it stopped

Ask of any automation: if this stopped working tonight, how would anyone know?

Uncomfortably often the honest answer is that someone notices in a few weeks when a number looks wrong. Scheduled workflows are especially prone to this, because a job that does not run produces no error — it produces nothing at all, which looks identical to a quiet day.

A build that lasts has a heartbeat: a count that should be non-zero, a control total that should tie back to the source, an alert when a run does not happen rather than only when a run fails.

5. It can be handed over

This is the one people underestimate, and the one that determines whether the automation outlives whoever commissioned it.

Six months on, the person who built it has moved on and something needs changing. What exists? If the answer is a canvas of nodes named HTTP Request 3 and If 2, the practical cost of any change is a rebuild.

What should exist:

• Nodes named for what they do, not what they are
• Notes on the canvas explaining the non-obvious decisions, in the place you would look
• Configuration grouped in one step, not scattered through fifteen
• A plain-English runbook covering every connection, every credential, and what to check first when something looks wrong

6. You own it

An automation that runs in someone else's account, on someone else's connections, is a dependency wearing the costume of an asset. If the relationship ends, so does the workflow.

A build that lasts runs in your account, on your credentials, and can be exported and read by someone who has never met the person who wrote it.

The short version

If you are commissioning a build, six questions cover most of it:

• What happens when the far end times out and we do not know if it worked?
• Where does a malformed record go?
• Which errors get retried, and which do not?
• How would we find out if this stopped running?
• What does somebody read in six months to understand this?
• Whose account does it run in?

None of these are exotic. They are the difference between an automation you stop thinking about because it works, and one you stop trusting because it does not — and you can ask all six before any money changes hands.