Error handling for client automations in n8n and Make

Short answer

In n8n, create an error workflow that starts with the Error Trigger node and assign it in each workflow's settings. In Make, add error handlers to the modules that tend to fail and turn on incomplete executions for important scenarios. Then decide, with the client, who gets the alert and what you do about it.

n8n: error workflows

n8n's documentation describes an error workflow as one that runs when another workflow's execution fails. You can use it, for example, to send an email or Slack alert. The steps in the docs:

1. Create a new workflow with the Error Trigger as the first node.
2. Name it something like Error Handler and save it.
3. In the workflow you want to protect, open Options, then Settings, and choose that workflow in the Error workflow field. Save.

A few details from the docs that catch people out:

• The Error Trigger only runs when a workflow fails automatically. You cannot test it by running the workflow manually.
• If the failure is in the trigger node itself, the error data is different. There is less information about the execution and more about the trigger.
• Execution ID and URL are only included if the execution is saved in the database, and not when the error is in the main workflow's trigger node.
• You can use the Stop And Error node to make a workflow fail on purpose in a case you define, for example when a required field is empty. That also fires the error workflow.

For a client, a useful alert has: the workflow name, the failing node, the error message, and a link to the execution. Send it to a place you will actually see.

Make: error handlers and incomplete executions

Make's help pages describe error handlers as modules connected to another module that catch an error so the scenario does not simply stop. The options listed are:

• Skip: drops the failing bundle and continues. The run is marked a success.
• Retry: stores the failing bundle as an incomplete execution and lets the rest continue. The run ends with a Warning.
• Resume: swaps in a substitute value for the failed module and continues.
• Commit: stops the scenario and saves the changes made so far.
• Rollback: stops the scenario and reverts changes in modules that support transactions.

Make says Rollback is the default if you set no error handling and keep incomplete executions off. With incomplete executions on, a failed scenario is stopped and parked in the Incomplete executions tab, a manual queue that you work through, fix the cause and resume. Make also says the most frequent errors are RateLimitError and ConnectionError.

Make's own question for choosing a handler is a good one to ask the client: what is the impact of this error? If a bad row changes nothing important, Skip may be fine. If an unpaid invoice never gets sent, it is not.

Decide these things with the client

Before you promise monitoring, write down:

• Who receives the alert. A client who never opens a shared inbox will not see it.
• What counts as an emergency and what can wait until the next working day.
• What you will do within your response time: look, fix, or tell them it needs a decision.
• Who owns the accounts and credentials. If a client's API key expires, only they may be able to renew it.
• What it costs. A fix caused by your mistake is yours. A fix caused by a change in someone else's app is a billable change, if your agreement says so.

See how to price n8n and Make work for retainer versus hourly. The same structure works for Shopify stores, as in store care retainers.

A basic monthly routine

For each client, once a month:

1. Look at failed and incomplete executions since the last check.
2. Check for credential or token warnings in the connected apps.
3. Confirm the key workflows ran at the times they should.
4. Send the client two or three lines. What ran, what failed, what you fixed.

That short note is what the client sees for their fee. Without it, a retainer looks like nothing happened.

Sell it as a fix, not a feature

Most small businesses will not ask for "error handling". They ask why last week's orders never reached the spreadsheet. If you build with alerts from the first day, you can show them what the alert looked like when something broke, and how long the fix took. Do not invent that history. Use real events from your own workflows or from the demos you built. If you have none yet, describe what the alert would show.

If you are still looking for the first clients to offer this to, start with how to become an n8n freelancer.

If you want help finding the work

Thomas Partners finds client work such as fixing broken automations and runs it under your name. You keep 90% of the profit after documented costs are repaid, and if there is no profit there is no fee. You can apply here.