Monitoring your n8n workflows: no silent failures

A forgotten manual task eventually shows. A broken automation does not. Orders are no longer copied over, invoices are no longer created, and the first signal may come from a customer, days later. Monitoring your n8n workflows means making sure that signal reaches you, straight away, with what you need to fix it.

We operate n8n workflows in production, including an expense-entry agent on Telegram and the one that assigns an internal identifier to each new property in the CRM of Palmora Property, a property portal we work with. This guide draws on n8n’s documentation and on our own incidents. Choosing the tool and the case of software with no API are covered in the other guides in our Automation and bots section.

How do you get warned when an n8n workflow fails?

n8n lets you designate, for each workflow, an error workflow that starts when an execution fails. According to the documentation on error handling, this workflow must start with the Error Trigger node, and the same one can serve several workflows. So you build it once, carefully:

1. 01Create the error workflow.

   Its first node is the Error Trigger. Give it a clear name (“Alerts”, for example) and save it: it does not need to be published to work.

2. 02Connect the alert.

   Add after the Error Trigger the step that sends the alert to your team’s channel.

3. 03Attach it to each workflow.

   In each workflow to monitor, open the settings (Settings) and choose this workflow as the Error Workflow.

4. 04Test.

   Cause a failure on an automatic execution to check that the alert does arrive.

The fourth step matters: according to the node’s documentation, the Error Trigger only fires when an automatic execution fails, never on a manual run. For the test, the Stop And Error node makes an execution fail under the conditions you choose.

What a good alert must contain:

• the name of the process in business language (“Supplier invoice creation”, not “Workflow 14”);
• the step that failed and the error message;
• the link to the failed execution, which n8n provides if the execution is saved (not when the error comes from the trigger itself);
• what the person receiving the alert should do, or who to call.

The channel matters as much as the content. One more email in an overflowing inbox is useless: the alert must arrive where the team already reads, in a channel reserved for alerts, which stays silent when all is well. On Palmora Property, that means two dedicated Discord channels.

How do you know what has been processed, and what has not?

n8n keeps a record of executions. The list of executions can be filtered by workflow, by status (failed, running, successful, waiting) and by start date, and you can open an execution to see its data, step by step. It still has to have been kept, and that can be configured:

• What is recorded. According to n8n’s documentation, each workflow’s settings decide whether to keep failed production executions, successful ones, and manual executions. Always keep the failures. Also keep the successes of an important process: it is the only proof that a job took place when someone asks whether Tuesday’s order went through.
• For how long. On a self-hosted instance, n8n by default deletes completed executions beyond 14 days or 10,000 executions, starting with the oldest, according to its documentation on execution data. Set these thresholds according to your needs, remembering that the history contains your data: names, amounts, addresses.
• What disappears with the workflow. Deleting a workflow also deletes its execution history. Switch off rather than delete a process you might be called to account for.
• Steps named in plain language. An execution should be readable without its author: “Create the invoice” rather than “HTTP Request 3”.

For an important process, consider a separate log: one line per item processed (invoice X, customer Y) with its status, which the business person can consult without opening n8n and which does not depend on the tool’s purge.

How do you rerun an execution without creating a duplicate?

Once the cause is fixed, what remains is to process what was not processed. From the executions list, n8n reruns a failed execution in two ways: with the workflow as it is saved today, that is, corrected, or with the original workflow. To understand a failure before rerunning, the Debug in editor function, described in its documentation, copies the data of a past execution into the editor, pinned on the first node (self-hosted, depending on your edition). The Save execution progress setting also lets you resume where the execution stopped, at the cost of a little latency.

The trap is the duplicate. If a workflow created the invoice and then failed when sending the email, rerunning it from the start creates a second invoice. The defence is built at design time, not during the outage:

• every step that writes checks first whether the item already exists, using a reference identifier (order number, supplier invoice number);
• the most important record comes before the side actions (notification, email), never after;
• one failed item does not stop the others: in a batch of fifty invoices, the forty-seventh failing must not block the three that follow.

A client learned the second rule the hard way.

How do you spot a workflow that succeeds with wrong data?

A workflow can succeed and produce a wrong result: an empty export processed “successfully”, an amount read as zero because the format changed, a PDF whose extraction missed a field. None of these cases triggers the error workflow. On Palmora Property, without publication safeguards, an empty API response would publish a site with zero products, with a green workflow.

A few simple checks catch these cases:

• a volume threshold: markedly fewer items than on an ordinary day, or none, and nothing is published until a person has looked;
• a deletion check: a job that is about to delete far more than usual stops and warns you;
• required fields checked before writing (no invoice without an amount or a supplier);
• a human review queue for anything doubtful, rather than an automatic write.

In n8n, the Stop And Error node turns a failed check into a real failure:

These checks matter even more when the automation goes through a back door (export, email, screen), as in our guide to automating software that has no API: a change of format on the source side quickly gives a wrong result with no visible error.

Should you also monitor the server that runs n8n?

If n8n is self-hosted, yes: the server is part of the set-up. A stopped instance sends no alert, since it does nothing any more. At a minimum:

• an external probe, which runs somewhere other than on the monitored server and checks that the instance responds;
• the disk: according to n8n’s documentation, the database can grow until it fills the storage; keep nothing unnecessary and leave the purge on (on SQLite, the space freed is not automatically given back);
• backups and updates, where we detail what really breaks in our article on backing up a server of your own.

What should you check before putting a workflow into production?

A workflow that does not tick these six boxes is not in production: it is on trial, and someone needs to know it.

This is what we deliver in our offer: every automated process comes with its alerts and the history of each execution, plus a cost-per-execution counter, and the old way of working stays as a fallback until the new one has proved itself. Monitoring and fixes are included for at least 3 months, at €350 a month, then continue month to month.

Frequently asked questions

Sources

1. The documentation on error handling (new tab)docs.n8n.io
2. List of executions (new tab)docs.n8n.io
3. Its documentation on execution data (new tab)docs.n8n.io