Error handling and retries: how do you stop a workflow from failing silently?

A workflow that runs fine in testing and then fails quietly in production is the default outcome, not bad luck. Most tools stop or skip a step on error and continue without telling you. You find out days later when a record is missing or a customer did not get their email. A workflow fails silently unless you add a path that handles the failure and tells someone. Here is how people usually set that up, with n8n as the concrete example, though the same ideas apply in Zapier and Make.

Retry the failures that are temporary

A lot of errors are temporary. An API times out, or you reach a rate limit for a few seconds. In n8n you handle these at the node level with Retry On Fail, where you set the number of tries and the wait between them (n8n docs). Zapier and Make have their own automatic retries for the same kind of error. The point is to separate temporary failures, which a retry fixes, from permanent ones like a renamed field or a bad credential, where retrying the same call just wastes time. Retries alone do not make failures visible. They only reduce how often you reach the failure path.

Catch what still fails and tell a human

This is the part most setups miss. Failures get caught by the tool, but nothing routes them to a place a person looks. In n8n you create one separate workflow that starts with the Error Trigger node, then set it as the Error workflow in a workflow's settings. It runs automatically whenever an execution fails, and one error workflow can serve many workflows (n8n docs). The data it receives includes the error message, the last node that ran, and a link to the failed execution, so your alert can say what broke and where. A useful error handler usually does three things. It sends an alert to somewhere you actually read, like Slack or email, with the workflow name and the failing node. It writes the failed item to a log or a separate table so you can review or reprocess it later. And it includes the execution link so you can open the exact run instead of searching for it.

Do not hide failures to make them stop showing up

There is a common mistake here. When errors are annoying, people turn on continue-on-fail across the whole workflow so nothing stops. That does not fix anything. It converts a visible failure into a silent one further down, and now a later step runs on missing or half-processed data. Use continue-on-fail only on steps where skipping a bad item is safe, and route that item to your error path. For the opposite case, where bad data should not move forward at all, n8n has a Stop And Error node that forces the run to fail on your condition, so it reaches your error workflow instead of passing the bad data on (n8n docs).

How do you handle this in your own workflows? Do you send every failure to one alerting workflow, or handle errors separately in each one?