When automations fail

The first automation I built ran cleanly for three weeks and I was proud as punch. Then on a Tuesday the API on the other side was briefly gone, the workflow broke off mid-run, and a customer got two confirmation emails instead of one. Nobody had told me something had gone wrong. I only noticed when the customer complained.

That is the moment most people realise: building an automation is one half. Building it so it does not break anything when something goes wrong is the other. And that is exactly what this is about.

In the previous lessons you learned how Zapier and n8n work and what a webhook is. Now we look at what happens when that webhook does not answer. Because at some point it will not.

Why automations fail in the first place

An automation is a chain. Trigger, then step one, then step two, and so on. Every step usually talks to some foreign system, an API, a database, a mail server. And foreign systems are exactly that: foreign. You have no control over them.

The most common reasons a step dies are mundane. The other side is overloaded right now and answers with an error. The connection takes too long and runs into a timeout. A record has a field you did not expect, empty or in the wrong format. Or a limit is reached, too many requests in too short a time.

The tricky part: these errors are usually temporary. A second later the same call would have worked. That is exactly why the first line of defence is not some complicated construct but simply trying again.

Retry, simply try again

Both major tools have this built in, and you should switch it on almost always.

In n8n the setting is called Retry On Fail and sits directly on every individual node, in the node settings. You give two values: Max Tries, so how many attempts at most, and Wait Between Tries (ms), so how long to wait in between. A good starting value for most cases is Max Tries 3 and Wait Between Tries 1000, so three attempts with a one second pause. Worth knowing: the UI caps these values. Max Tries goes up to 5 at most, the wait time up to 5000 milliseconds. If you need longer pauses or more attempts, you have to help yourself with your own loop logic, but that is no longer a beginner topic.

In Zapier it works the other way round. Instead of configuring retries in advance, you work with Replay. A failed Zap run lands in the Zap history with status errored, and you can replay it from there. On the free plan that works manually and only for runs with error status. Anyone wanting it automatically needs Autoreplay, a setting that replays failed runs by itself. That is only available from the Professional plan upwards though. A detail many people trip over: if you change the Zap heavily after the error, the old failed runs can no longer be repeated cleanly.

Retry solves a surprising number of problems. But not all. And this is where it gets interesting.

The problem with running twice

Imagine your workflow does two things. First create an order in the database, then send a confirmation email. The database works, the email works, but after that the workflow dies for some silly reason. Retry starts the whole run again. Result: second order, second email. Exactly my Tuesday problem from above.

The technical term for this is idempotency. An operation is idempotent when it does not matter whether it runs once or five times, the result stays the same. Flipping a light switch to on is idempotent, pressing on five times changes nothing. Creating a new order is not, every run creates another one.

In practice you solve that with a unique key. Every order gets an ID, for example the order number. Before your workflow creates a new order, it checks: is there already an entry for this ID? If yes, skip. That turns the dangerous "create again" into a harmless "already there, carry on".

You do not have to do that everywhere. But everywhere your workflow creates or sends something a human will see or pay for, the thought is worth it. Better to check one time too many than to send a customer two invoices.

Where to put the cases that simply will not go through

Sometimes no retry helps. The record is broken, a mandatory field is missing, the logic does not fit. If you simply let such a case slip through, it disappears silently and you never find out.

The idea to remember here is called dead letter, roughly the mailbox for undeliverable post. Instead of throwing a broken record away or blocking the whole workflow, you push it aside. Into its own Google Sheet, into a table, into a separate channel. There the cases that need a hand collect, and the rest keeps running.

In n8n you use the option Continue (using error output) on the HTTP request node for that. Instead of aborting the workflow, the node opens a second output for the error case, and you hang your push-aside logic on that output. In Zapier you build the same effect with paths and the decision about how a Zap handles errors.

The point is always the same. A single broken record must not stop the whole machine, and it must not vanish without trace either.

You have to find out when something is burning

That is the lesson the complaining customer taught me. The best error handling is worth nothing if you do not learn that something happened.

Alerting simply means: when a workflow fails, a message goes out to you. An email, a Telegram message, an entry in a Slack channel. n8n has its own mechanism for this, which you can register as an error workflow, so a notification goes off automatically on an abort. In Zapier you can have yourself notified by email when a Zap goes to error status.

What matters is only that the message tells you concretely what happened. "Workflow order failed" is worth half as much as "workflow order failed, step mail dispatch, order number 4815, error timeout". With the second variant you know immediately where to look.

And an honest piece of practical advice: do not make your alerting too loud. If every small, self-healing retry sends you a message, you stop looking after three days. Report the cases that genuinely need a hand, not every hiccup.

How to approach this now

You do not have to build everything at once. Start small. Go through your existing automation and switch on retry at every step that talks to a foreign system. Three attempts, one second pause. That already catches most of the temporary errors.

Then think about which step creates something you must not have twice, and build an idempotency check in there. And finally set up a single notification that tells you when a workflow has failed completely. That is all you need to start with.

In this level's capstone you build a complete automation. Take this with you into it. An automation that only works in fair weather is a prototype. One that breaks nothing in the rain too is a tool.

Sources

• n8n Retry On Fail, Max Tries and Wait Between Tries, as well as Continue using error output on the HTTP Request node: https://n8nautomationtutorial.com/n8n-http-request-node-retry-on-fail-error-handling-retry-logic
• n8n community on the UI limits Max Tries 5 and Wait Between Tries 5000 ms: https://community.n8n.io/t/node-max-tries-wait-values-limits-too-low/46284
• Zapier Replay Zap runs: https://help.zapier.com/hc/en-us/articles/8496241726989-Replay-Zap-runs
• Zapier Autoreplay and error behaviour (Professional plan upwards): https://help.zapier.com/hc/en-us/articles/14167175792909-Decide-how-your-Zap-handles-errors-with-advanced-settings