Hello and welcome to video number seven of the beginner course for n8n. In this video, we'll be covering how past executions are stored for your workflows and, uh, specifically how to handle workflow errors, which is a very important skill.

Let's start a little bit by talking, uh, about how executions are stored in n8n.

So for now, most of the executions that we've been working with have been manual executions in these past videos.

We've been clicking on execute workflow or test step, but as mentioned previously, when we activate a workflow, we're going to be turning on the automation, and so the workflow is going to execute behind the scenes without us necessarily seeing the execution of the workflow.

We can access the, um, history of all of our workflows executions in what we call the execution log, which you can access by clicking on all executions.

By default, successful and failed production executions, so when workflows are activated, those are saved, and manual executions are not saved.

However, on a per workflow basis, you can activate the logging of manual executions.

You can sort the execution log by workflow status, date ranges, or even execution data. Uh, we'll cover how to store execution data in the logs in the advanced course.

For the execution log, you can access the individual execution histories. Um, so here you can see an example of an execution history. We can see the schedule trigger that activated, we read the data in the sheets, and depending on if the email existed or not, we messaged sales or marketing.

These are static because they are past executions, and so they cannot be changed. This is a snapshot of the final state of all of the nodes from that given execution.

This is very useful when debugging, fixing, or inspecting workflows. You can look through past executions to understand how the workflow works.

You can open, of course, each node by double clicking on it to see what the input and output data was, as well as all of the node settings.

And if the node has an error, you will also get the details about that error um from the um, from double clicking on the node.

So as we mentioned earlier, sometimes executions can fail. You're going to activate a workflow or push it to production, and sometimes your settings aren't going to be optimal or your input data is going to be in the wrong format, and this is going to cause your workflow to fail.

So there can be multiple reasons that workflows fail, and it's important to understand what kinds of errors there are and especially how to fix them.

The first method of handling errors, and this is a very important one, is to use the error workflow. The error workflow is a workflow that is executed as soon as a node has an error, and this workflow allows you to report on any workflows that have errors, pretty much informing you when your workflow needs to be uh debugged or fixed because it failed.

This workflow needs to be configured for every new workflow, so when building workflows, make sure to set your error workflow.

Um, you can have one or multiple error workflows in your n8n instance. Here we have an example. Uh, this workflow is launched every day at 8:00 a.

m. It reads contacts in a Google Sheets and updates the CRM, in this case Salesforce, with those contacts.

The email field is mandatory in Salesforce, and so it will cause an error when trying to create a contact for items that do not have an email.

This triggers the error workflow with information on the node that had an error, in this case, the Salesforce node.

So here, of the 10 items that we read in the sheet, some of them didn't have an email, and this caused the Salesforce node to, um, have an error.

Another way to trigger the error workflow is with the Stop and Error node, and this, uh, node is, um, will raise an error message every time that it is, uh, triggered, every time that it is executed, and you can configure that specific error message.

Once triggered, you have multiple options.

By default, the whole workflow will be stopped and its status will be set to failed. Um, however, we'll look at this, um, in n8n. You can choose the behavior of the Stop and Error node.

You can use this to manage edge cases in your workflows by raising errors when certain conditions are met that should not be met.

This workflow raises an error when the email data from the web hook is not valid. So here, we check if the web hook contains a valid email, and if not valid, we stop and error.

Uh, the error workflow is created using the error trigger node that we'll take a look at in a second.

This node will output any, uh, and all information related to the workflow, so it will contain the name and workflow ID, the execution ID, as well as the links to find that specific execution that has an error, um, as well as information about the node that had an error, so either a specific node or the Stop and Error node.

We always recommend having, uh, a place, usually a channel—this can be Slack, WhatsApp, Teams, or any communication tool where you can report on errors, so people in your team with n8n access can see that the workflow had an error and quickly jump in to debug and fix the workflow.

So here, you have an example error workflow, an error trigger that sends a Slack message, an email, or a Telegram. You probably don't need all three, but you probably need somewhere where you can report on errors in your workflows.

Let's jump into n8n and see how we can use errors and build a super simple error workflow.

So here we are back in n8n, and let's build a super simple error workflow. So we're going to call it error workflow, and the first step we're going to add is an error trigger.

When we add the error trigger, we can fetch a test event to understand, you know, what kind of data we will receive when the error trigger is, well, triggered.

So in this example, we're just going to build a very simple error workflow with a Slack message containing information about the error, so that someone can go and quickly take care of it and debug.

So here we have our error trigger and our test events. I can just come in here and, as usual, add a Slack node to send a message to myself, user Maxim, and here just to test, we're going to say 'n8n error'.

Then we're going to include some information, so workflow, colon, the name.

We're also going to include the execution URL here, and then going to include the error message.

Error message. This way, every time that we have an error and the error workflow is executed, we instantly know which workflow has an error.

Then we have a very quick link to access the specific execution, so we can go into n8n and see what the error was, and we also have an error message, so we can better understand what that issue was.

So here I can test the step, receive the message, and once we've tested, I can change and here not send to a user, but send instead to a channel, and here I have a and then errors and any errors channel again.

I can test that step and every time from now on one of my workflows has an error and the error workflow is called, I will get that message in an 'Errors' channel with the information about that execution.

In the advanced course, we'll cover a bit more of a complex error workflow, uh specifically with um tagging people, tagging the owners, um so we can get the right people to take a look at uh the errored execution.

Now jumping into uh the workflow from the previous video, uh just cleaned up a little bit. Instead of having those two ifs, I put a switch in place and I renamed the nodes so it's a little bit clearer.

Again, we have our web hook input data with the event type and information about the contact.

And depending on if the event is equal to account created or team member invited, we're going to be sending different messages here.

We might want to handle some potential errors. So there are two main potential errors that I could imagine.

First, we're looking at the email and second of all, we're checking what kind of event uh we're handling. So there are two kinds of error handling methods we could use here.

The first one is to check if the email is valid. So here we could do a pretty basic check and say, is, does the email contain an @ symbol?

That could be the maybe simplest way of making sure we have a valid email.

More complex ways could be to use uh regxes, make to make sure that um the email matches a very specific email format.

For now, let's just um check if the email contains an @ symbol. So for example, this would be email valid if the email is valid, we can just continue the workflow.

And if the email is not valid, then we can add a stop and error and here we can throw an error message or an error object simply mentioning, um, invalid email.

Then here we have settings on, sorry, we have a switch on the event type. We could also imagine that we might not have a valid event.

So here in the switch, I could add a new routing rule and this could be if the event is, does not exist, or as we saw earlier, if the events as an expression obviously is equal to an empty string, and both of these outputs we could then drag to a stop and error and this time instead of having invalid email, we could say invalid event.

Now we know that when this workflow activates, it'll handle both the case of an invalid email and the case of an invalid event.

So if we do have any errors in our web hook, uh, system, that will trigger error workflows and then we can go in and check why did we not have an email or why did we have an invalid event?

One more thing to mention here in the Stop and error workflows, if we head over to the settings, we're going to be able to select what kind of behavior we want on error.

As mentioned in the slides, by default, this will stop the workflow, but if you are handling with an edge case that doesn't prevent the workflow from continuing, you might want to continue or continue using an error output.

Um, so this can be configured on a node per node basis both for stop and error workflows as well as, uh, just usual um, nodes.

Thanks for listening to the seventh video of the n8n beginner course where we looked into execution histories, error handling, and a very basic error workflow.

In the next video, we'll be covering how to debug a workflow to avoid it from having errors again, as well as retrying.

n8n Beginner Course (7/9) - Error handling

Scripts