An automation that needs a babysitter is not done
If someone has to notice it stopped, re-run it, and clean up by hand, you built a job description with extra steps. Not an automation.
The short version
5 things that decide this
- 01A workflow that a person re-runs every Monday has a manual step in it. The step is just called 'checking the automation'.
- 02Done has four parts: retries with backoff on anything that calls another service, writes that survive being sent twice, a dead-letter queue a human actually opens, and an alert that names the broken step.
- 03Most tutorials build the happy path only, because the happy path is what fits in a video.
- 04Little Tree Confections' meeting-to-task pipeline keeps execution logs and error handling as part of the build, not bolted on after a failure.
- 05None of the four needs new tooling. They need to be treated as part of the job, not left for whoever notices first.
How you can tell an automation isn't done
Ask who checks the automation, and how often. A clean answer is 'nobody, it alerts if something breaks.' A telling answer names a day: 'Sarah looks at it Monday mornings.'
Sarah is doing the job the automation was supposed to remove. She just does less of it, on a schedule nobody wrote down, using judgment nobody documented. When she's on leave, the checking stops. Nobody planned that either.
This is not a Sarah problem. It's a definition-of-done problem. Most no-code tutorials demo the happy path: trigger fires, data flows, task appears. They stop there because a fifteen-minute video has no room for what happens when the third-party API times out.
Four things that separate a demo from a system
None of these need paid tooling beyond what n8n, Make, or Zapier already offer. They need someone to decide the failure path before the workflow ships, not after it breaks in front of a customer.
- 01Retries with backoff: a step that calls another API waits and tries again on a timeout or a rate limit, instead of treating a five-second outage the same as a real failure. Backoff means the wait grows between attempts, so a struggling service isn't hit harder while it recovers.
- 02Idempotent writes: retrying the same action twice must not create the record twice. An idempotency key, sent with the request and checked by the server, is the standard fix for anything that creates state, such as a charge or an invoice.
- 03A dead-letter queue someone checks: a run that fails after retries lands somewhere with its input data attached, ready to fix and replay. A queue nobody opens is the same as no queue.
- 04Alerts that name the broken step: 'workflow failed' tells a person to go investigate. 'ClickUp task creation failed for department Marketing, retry 3 of 3' tells them what to fix.
What this looks like on a real build
Little Tree Confections runs an n8n pipeline that turns every Fireflies meeting transcript into ClickUp tasks. Each one routes to the right department with no manual handoff. A second daily workflow builds a CEO brief and fires deadline reminders on its own schedule.
Error handling and execution logs are part of that build, not something added after a transcript went missing. The workflow reads the current ClickUp department list at run time instead of a hardcoded copy. A department rename doesn't silently misroute a task, and it doesn't need an emergency fix either.
That's the standard applied, not a special case. Any workflow touching a real operation faces the same four questions: what happens on a repeat call, what happens on a failed call, where a failed run lands, and who gets told.
Questions this raises
01How do I add retry with backoff in n8n?
Most n8n nodes that call an external service have a Retry On Fail option with a configurable wait time and attempt count. Set the wait to grow between attempts, not fire at a fixed interval. That way a struggling API isn't hit at the same rate that broke it. For calls outside n8n's built-in retry, wrap the HTTP request node in an error branch that reschedules the item instead of dropping it.
02What makes a workflow's writes idempotent?
Send a unique key with each write, generated once per action and reused on every retry of that same action. The receiving system checks the key first. Seen it before, it returns the existing result. New key, it does the work and stores it. This is what stops a retried request from creating a duplicate invoice, task, or charge.
03Do I need a dead-letter queue for a small automation?
If the workflow touches customers, invoices, or task assignment, yes, even a simple one. A dedicated ClickUp list, spreadsheet row, or database table that failed runs land in, with their input data attached, is enough. The point is a fixed place to look, not a specific tool.
Related
- Idempotency key →How a unique key stops a retried request from doing its work twice.
- n8n in production →Our review of the tool this pipeline runs on.
- Business process automation →The service behind builds held to this standard.
- Little Tree Confections: meeting-to-action automation →The production workflow this piece draws from.
