An automation that works the day you build it is not the same thing as an automation that works. The gap between those two is where most of the disappointment with business automation comes from.
Here is the pattern, which is remarkably consistent regardless of tooling.
Automations do not decay. Their assumptions do.
The workflow you built is still doing exactly what you told it to. What changed is the world around it:
- An API version was deprecated and the endpoint now returns something slightly different
- A field was renamed in the CRM by someone tidying up
- A credential expired, or a password rotation invalidated a token
- A form gained a field, and now the mapping is off by one
- A third party added rate limiting
None of these announce themselves. Most of them do not even produce an error: they produce wrong output, which is considerably worse.
The three failure modes, in order of how much they cost
1. Loud failure. The run errors, you get an alert, someone fixes it. This is the good outcome. Aim for it.
2. Silent wrong output. The workflow completes successfully while doing the wrong thing: writing to the wrong field, mapping to the wrong customer, sending the wrong template. Nothing looks broken. This surfaces weeks later, usually via a confused customer.
3. Silent absence. The workflow stops triggering entirely. Zero errors, because zero runs. This is the most expensive failure because there is nothing to notice: no red mark, no failed job, just an absence that looks identical to a quiet week.
Most monitoring catches only the first one.
Build for the failure you will actually get
Give every workflow an error path. Not a try/catch that swallows the problem: an actual route that alerts a named person. "It failed and nobody knew" is a design decision, even when it is an accidental one.
Make retries idempotent. If a workflow can run twice on the same input, it must not double-send, double-charge, or double-create. Key on a stable identifier and check before acting. Retry logic without idempotency turns a transient network blip into a customer complaint.
Alert on absence, not just errors. This is the one almost everybody misses. If a workflow normally runs about forty times a week and it has run zero times in three days, that should fire an alert. Monitoring for expected-runs-that-did-not-happen catches failure mode three, and nothing else does.
Validate before you act. If the incoming data does not look like what you expect (a missing required field, an implausible value, an empty list where there is always at least one item) stop and flag it rather than proceeding confidently.
Version the workflow definitions. Export them into source control. A workflow that exists only inside a running instance is one bad upgrade from gone, and "we will rebuild it from memory" is optimistic.
Split the big ones up
One enormous workflow that does everything is very hard to debug and very easy to break. Three smaller workflows with clear boundaries will cost slightly more to build and dramatically less to maintain.
When something fails at step 34 of a 60-step workflow, you want to be looking at a focused piece of logic, not scrolling.
The uncomfortable part
Building the automation is maybe half the work. The error handling, idempotency, alerting, and monitoring are the other half, and they are the half that gets cut when someone wants it working by Friday.
That trade is occasionally correct: for something genuinely low-stakes and easily reversed. It is not correct for anything touching customers, money, or records you rely on.
If you are evaluating someone to build automation for you, ask what happens when it fails. If the answer is vague, you are buying a demo rather than a system.
More on building n8n workflows that survive, or tell us what keeps breaking.