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

이 비디오에서는 n8n 워크플로우 실행 기록 관리 및 오류 처리 방법에 대해 설명합니다.

오류 워크플로우를 구축하여 오류 발생 시 알림을 받고, 중지 및 오류 노드를 사용하여 특정 조건에서 오류를 발생시키는 방법을 소개합니다.

유효성 검사를 통해 워크플로우의 잠재적 오류를 처리하고, 슬랙과 같은 채널을 통해 오류 정보를 공유하여 신속하게 디버깅할 수 있도록 안내합니다.

**'모든 실행' 로그를 통해 워크플로우 실행 기록에 접근**할 수 있습니다. 여기에는 성공 및 실패한 프로덕션 실행이 포함되며, 수동 실행 로깅은 워크플로우별로 활성화할 수 있습니다. 실행 로그를 통해 과거 실행을 디버깅하고 워크플로우의 작동 방식을 이해할 수 있습니다.

각 노드를 더블 클릭하여 입력 및 출력 데이터, 설정을 확인하고, 오류가 있는 경우 해당 오류에 대한 세부 정보를 얻을 수 있습니다. **과거 실행은 변경할 수 없으며, 각 노드의 최종 상태 스냅샷을 제공**합니다.

🚨 오류 워크플로우 설정의 중요성

오류 워크플로우는 워크플로우에서 오류가 발생할 때 즉시 실행되어 오류를 보고하는 중요한 기능입니다. **워크플로우를 구축할 때 오류 워크플로우를 설정해야** 합니다. 이는 모든 새로운 워크플로우에 대해 구성되어야 합니다.

오류 워크플로우의 예시로, 매일 오전 8시에 시작하여 Google Sheets에서 연락처를 읽고 Salesforce를 업데이트하는 워크플로우를 들 수 있습니다. **이메일 필드가 필수 항목인 Salesforce에서 이메일이 없는 연락처를 만들려고 하면 오류가 발생**하고 오류 워크플로우가 트리거됩니다.

중지 및 오류 노드는 워크플로우에서 특정 조건이 충족되지 않을 때 오류를 발생시켜 엣지 케이스를 관리하는 데 사용됩니다. **이 노드는 트리거될 때마다 오류 메시지를 발생시키며, 특정 오류 메시지를 구성**할 수 있습니다.

예를 들어, 웹훅의 이메일 데이터가 유효하지 않을 때 오류를 발생시키는 워크플로우를 만들 수 있습니다. **유효하지 않은 이메일이 감지되면 워크플로우를 중지하고 오류를 발생**시킵니다.

⚙️ 오류 트리거 노드 심층 분석

오류 워크플로우는 오류 트리거 노드를 사용하여 생성됩니다. **이 노드는 워크플로우 이름, ID, 실행 ID, 오류가 발생한 노드 정보 등 워크플로우 관련 모든 정보를 출력**합니다. 이를 통해 오류가 발생한 특정 실행을 쉽게 찾을 수 있습니다.

일반적으로 슬랙, WhatsApp, Teams와 같은 커뮤니케이션 채널을 통해 오류를 보고하여 n8n 액세스 권한이 있는 팀 구성원이 워크플로우 오류를 신속하게 확인하고 디버깅할 수 있도록 하는 것이 좋습니다. **오류 트리거는 슬랙 메시지, 이메일, 텔레그램 등을 통해 오류를 보고**할 수 있습니다.

📧 유효성 검사를 통한 오류 방지

워크플로우에서 잠재적인 오류를 처리하기 위해 유효성 검사를 수행할 수 있습니다. 예를 들어, 이메일이 유효한지 확인하기 위해 **기본적인 검사(예: @ 기호 포함 여부 확인) 또는 정규식을 사용한 복잡한 검사를 수행**할 수 있습니다.

유효하지 않은 이메일 또는 이벤트가 감지되면 중지 및 오류 노드를 사용하여 오류 메시지를 throw할 수 있습니다. **워크플로우 설정에서 오류 발생 시 원하는 동작 유형(워크플로우 중지, 계속, 오류 출력 사용)을 선택**할 수 있습니다.

안녕하세요, n8n 초급 과정 7번 비디오에 오신 것을 환영합니다. 이번 비디오에서는 워크플로우에 대해 과거 실행이 어떻게 저장되는지, 그리고 특히 워크플로우 오류를 처리하는 방법을 다룰 것입니다. 이는 매우 중요한 기술입니다.

먼저 n8n에서 실행이 어떻게 저장되는지에 대해 간단히 이야기해 보겠습니다.

지금까지는 대부분의 실행이 지난 비디오에서 수동으로 실행되었습니다.

워크플로우 실행 또는 테스트 단계를 클릭했지만, 앞서 언급했듯이 워크플로우를 활성화하면 자동화가 켜지고 워크플로우 실행을 보지 않고도 백그라운드에서 워크플로우가 실행됩니다.

모든 워크플로우 실행 기록은 '모든 실행'을 클릭하여 액세스할 수 있는 실행 로그에서 확인할 수 있습니다.

기본적으로 성공 및 실패한 프로덕션 실행, 즉 워크플로우가 활성화된 경우 저장되고 수동 실행은 저장되지 않습니다.

그러나 워크플로우별로 수동 실행 로깅을 활성화할 수 있습니다.

워크플로우 상태, 날짜 범위 또는 실행 데이터별로 실행 로그를 정렬할 수 있습니다. 실행 데이터를 로그에 저장하는 방법은 고급 과정에서 다룰 것입니다.

실행 로그에서 개별 실행 기록에 액세스할 수 있습니다. 여기에서 실행 기록의 예를 볼 수 있습니다. 활성화된 스케줄 트리거를 확인하고 시트에서 데이터를 읽고 이메일 존재 여부에 따라 영업 또는 마케팅에 메시지를 보냈습니다.

이러한 실행은 과거 실행이므로 변경할 수 없습니다. 해당 실행의 모든 노드의 최종 상태 스냅샷입니다.

이것은 워크플로우를 디버깅, 수정 또는 검사할 때 매우 유용합니다. 과거 실행을 통해 워크플로우 작동 방식을 이해할 수 있습니다.

물론 각 노드를 더블 클릭하여 입력 및 출력 데이터와 모든 노드 설정을 확인할 수 있습니다.

그리고 노드에 오류가 있는 경우 노드를 더블 클릭하면 해당 오류에 대한 세부 정보도 얻을 수 있습니다.

앞서 말씀드린 것처럼 때로는 실행이 실패할 수 있습니다. 워크플로우를 활성화하거나 프로덕션에 푸시할 때 설정이 최적이 아니거나 입력 데이터가 잘못된 형식일 수 있으며, 이로 인해 워크플로우가 실패할 수 있습니다.

워크플로우가 실패하는 데에는 여러 가지 이유가 있을 수 있으며, 어떤 종류의 오류가 있는지, 특히 오류를 수정하는 방법을 이해하는 것이 중요합니다.

오류를 처리하는 첫 번째 방법은 매우 중요한 오류 워크플로우를 사용하는 것입니다. 오류 워크플로우는 노드에 오류가 발생하는 즉시 실행되는 워크플로우로, 오류가 있는 워크플로우를 보고할 수 있습니다. 즉, 워크플로우가 실패했기 때문에 디버그하거나 수정해야 할 때 알려줍니다.

이 워크플로우는 모든 새 워크플로우에 대해 구성해야 하므로 워크플로우를 구축할 때 오류 워크플로우를 설정해야 합니다.

n8n 인스턴스에는 하나 또는 여러 개의 오류 워크플로우가 있을 수 있습니다. 여기 예제가 있습니다. 이 워크플로우는 매일 오전 8시에 시작됩니다.

Google Sheets에서 연락처를 읽고 CRM(이 경우 Salesforce)을 해당 연락처로 업데이트합니다.

이메일 필드는 Salesforce에서 필수 항목이므로 이메일이 없는 항목에 대한 연락처를 만들려고 하면 오류가 발생합니다.

이로 인해 오류가 발생한 노드(이 경우 Salesforce 노드)에 대한 정보가 포함된 오류 워크플로우가 트리거됩니다.

여기서는 시트에서 읽은 10개의 항목 중 일부에 이메일이 없었기 때문에 Salesforce 노드에 오류가 발생했습니다.

오류 워크플로우를 트리거하는 또 다른 방법은 중지 및 오류 노드를 사용하는 것입니다. 이 노드는 트리거될 때마다, 실행될 때마다 오류 메시지를 발생시키며 특정 오류 메시지를 구성할 수 있습니다.

트리거되면 여러 옵션을 사용할 수 있습니다.

기본적으로 전체 워크플로우가 중지되고 상태가 실패로 설정됩니다. 하지만 n8n에서 이를 살펴보겠습니다. 중지 및 오류 노드의 동작을 선택할 수 있습니다.

충족되어서는 안 되는 특정 조건이 충족될 때 오류를 발생시켜 워크플로우에서 엣지 케이스를 관리하는 데 사용할 수 있습니다.

이 워크플로는 웹훅의 이메일 데이터가 유효하지 않을 때 오류를 발생시킵니다. 여기서 웹훅에 유효한 이메일이 포함되어 있는지 확인하고, 유효하지 않으면 중지하고 오류를 발생시킵니다.

어, 오류 워크플로는 잠시 후에 살펴볼 오류 트리거 노드를 사용하여 생성됩니다.

이 노드는 워크플로와 관련된 모든 정보를 출력하므로 이름과 워크플로 ID, 실행 ID는 물론 오류가 발생한 특정 실행을 찾을 수 있는 링크와 오류가 발생한 노드, 즉 특정 노드 또는 중지 및 오류 노드에 대한 정보도 포함됩니다.

일반적으로 슬랙, WhatsApp, Teams 또는 오류를 보고할 수 있는 모든 커뮤니케이션 도구와 같은 채널을 마련하여 n8n 액세스 권한이 있는 팀 구성원이 워크플로에 오류가 있음을 확인하고 신속하게 디버깅하고 수정할 수 있도록 하는 것이 좋습니다.

여기에는 슬랙 메시지, 이메일 또는 텔레그램을 보내는 오류 트리거인 오류 워크플로의 예가 있습니다. 세 가지가 모두 필요하지는 않지만 워크플로의 오류를 보고할 수 있는 위치가 필요할 것입니다.

n8n으로 이동하여 오류를 사용하고 매우 간단한 오류 워크플로를 구축하는 방법을 알아봅시다.

자, 여기 n8n으로 돌아왔습니다. 매우 간단한 오류 워크플로를 구축해 보겠습니다. 오류 워크플로라고 부르고, 가장 먼저 추가할 단계는 오류 트리거입니다.

오류 트리거를 추가하면 테스트 이벤트를 가져와서 오류 트리거가 트리거될 때 어떤 종류의 데이터를 받게 될지 이해할 수 있습니다.

이 예에서는 오류에 대한 정보가 포함된 슬랙 메시지를 보내는 매우 간단한 오류 워크플로를 구축하여 누군가가 가서 신속하게 처리하고 디버깅할 수 있도록 할 것입니다.

여기 오류 트리거와 테스트 이벤트가 있습니다. 여기에서 평소처럼 슬랙 노드를 추가하여 저 자신, 즉 Maxim 사용자에게 메시지를 보낼 수 있습니다. 여기서 테스트를 위해 'n8n 오류'라고 말하겠습니다.

그런 다음 워크플로, 콜론, 이름과 같은 일부 정보를 포함할 것입니다.

여기에서 실행 URL도 포함하고 오류 메시지도 포함할 것입니다.

오류 메시지입니다. 이렇게 하면 오류가 발생하고 오류 워크플로우가 실행될 때마다 어떤 워크플로우에 오류가 있는지 즉시 알 수 있습니다.

그런 다음 특정 실행에 액세스할 수 있는 빠른 링크가 있으므로 n8n으로 이동하여 오류가 무엇인지 확인할 수 있으며 오류 메시지도 있으므로 문제를 더 잘 이해할 수 있습니다.

여기에서 단계를 테스트하고 메시지를 받을 수 있으며 테스트가 완료되면 변경할 수 있습니다. 여기에서 사용자에게 보내지 않고 대신 채널로 보냅니다. 여기에는 오류 및 모든 오류 채널이 다시 있습니다.

해당 단계를 테스트할 수 있으며 지금부터 워크플로우 중 하나에 오류가 발생하고 오류 워크플로우가 호출될 때마다 해당 실행에 대한 정보가 포함된 '오류' 채널에서 해당 메시지를 받게 됩니다.

고급 과정에서는 좀 더 복잡한 오류 워크플로우, 특히 사람 태그 지정, 소유자 태그 지정을 다룰 예정입니다. 오류가 발생한 실행을 살펴볼 적임자를 찾을 수 있습니다.

이제 이전 비디오의 워크플로우로 넘어갑니다. 약간 정리했습니다. 두 개의 if를 사용하는 대신 스위치를 배치하고 노드 이름을 바꿔서 좀 더 명확하게 했습니다.

다시 말하지만, 이벤트 유형과 연락처에 대한 정보가 포함된 웹 후크 입력 데이터가 있습니다.

이벤트가 계정 생성 또는 팀 구성원 초대에 해당하는지에 따라 여기에서 다른 메시지를 보내게 됩니다.

잠재적인 오류를 처리해야 할 수도 있습니다. 그래서 제가 상상할 수 있는 두 가지 주요 잠재적 오류가 있습니다.

첫째, 이메일을 보고 있고 둘째, 어떤 종류의 이벤트를 처리하고 있는지 확인하고 있습니다. 따라서 여기에서 사용할 수 있는 두 가지 종류의 오류 처리 방법이 있습니다.

첫 번째는 이메일이 유효한지 확인하는 것입니다. 여기에서 매우 기본적인 검사를 수행하고 이메일에 @ 기호가 포함되어 있는지 확인할 수 있습니다.

이것이 유효한 이메일이 있는지 확인하는 가장 간단한 방법일 수 있습니다.

더 복잡한 방법은 정규식을 사용하여 이메일이 매우 구체적인 이메일 형식과 일치하는지 확인하는 것입니다.

지금은 이메일에 @ 기호가 포함되어 있는지 확인해 보겠습니다. 예를 들어 이메일이 유효한 경우 이메일 유효성이 검사되고 워크플로우를 계속할 수 있습니다.

이메일이 유효하지 않으면 중지 및 오류를 추가할 수 있습니다. 여기서 간단히 '유효하지 않은 이메일'이라고 언급하는 오류 메시지나 오류 객체를 throw할 수 있습니다.

여기 이벤트 유형에 대한 스위치가 있습니다. 유효한 이벤트가 없을 수도 있다고 가정할 수도 있습니다.

여기 스위치에서 새 라우팅 규칙을 추가할 수 있습니다. 이는 이벤트가 존재하지 않거나, 앞에서 본 것처럼 이벤트가 표현식인 경우 분명히 빈 문자열과 같은 경우일 수 있습니다. 이러한 출력은 모두 중지 및 오류로 끌 수 있습니다. 이번에는 유효하지 않은 이메일 대신 유효하지 않은 이벤트라고 할 수 있습니다.

이제 이 워크플로가 활성화되면 유효하지 않은 이메일과 유효하지 않은 이벤트의 경우를 모두 처리한다는 것을 알 수 있습니다.

웹후크 시스템에 오류가 있는 경우 오류 워크플로를 트리거하고 이메일이 없는 이유 또는 유효하지 않은 이벤트가 있는 이유를 확인할 수 있습니다.

중지 및 오류 워크플로에서 한 가지 더 언급할 사항은 설정으로 이동하면 오류 시 원하는 동작 유형을 선택할 수 있다는 것입니다.

슬라이드에서 언급했듯이 기본적으로 워크플로가 중지되지만 워크플로가 계속되는 것을 막지 않는 에지 케이스를 처리하는 경우 계속하거나 오류 출력을 사용하여 계속할 수 있습니다.

이것은 중지 및 오류 워크플로와 일반 노드 모두에 대해 노드별로 구성할 수 있습니다.

실행 기록, 오류 처리 및 매우 기본적인 오류 워크플로를 살펴본 n8n 초급 과정의 7번째 비디오를 시청해 주셔서 감사합니다.

다음 비디오에서는 오류가 다시 발생하지 않도록 워크플로를 디버깅하는 방법과 재시도 방법을 다룹니다.

n8n 워크플로우의 실행 저장 방식 및 오류 처리 방법 소개

n8n에서 실행이 저장되는 방식에 대한 간략한 설명.

'모든 실행'에서 워크플로우 실행 기록을 확인할 수 있음.

기본적으로 활성화된 워크플로우의 성공 및 실패 실행만 저장됨.

워크플로우별로 수동 실행 로깅을 활성화할 수 있음.

실행 로그에서 개별 실행 기록에 접근하여 워크플로우 작동 방식을 이해할 수 있음.

노드를 더블 클릭하여 입력/출력 데이터 및 노드 설정 확인 가능.

워크플로우 실패 원인과 오류 수정의 중요성

오류 워크플로우를 사용한 오류 처리

오류 워크플로우는 노드에 오류 발생 즉시 실행되어 오류 보고.

새 워크플로우 구축 시 오류 워크플로우 설정을 권장.

n8n 인스턴스에 하나 또는 여러 개의 오류 워크플로우를 설정할 수 있음.

오류 발생 노드에 대한 정보가 오류 워크플로우에 포함됨.

중지 및 오류 노드를 사용한 오류 처리

중지 및 오류 노드는 트리거될 때마다 오류 메시지를 발생시킴.

워크플로우에서 엣지 케이스 관리 시 특정 조건 충족 시 오류 발생시킬 수 있음.

오류 워크플로우는 오류 트리거 노드를 사용하여 생성됨.

오류 트리거 노드는 워크플로우 관련 정보(이름, ID, 실행 ID, 오류 노드 정보)를 출력.

슬랙, WhatsApp, Teams 등 오류 보고 채널을 통해 팀 구성원이 오류를 확인하고 디버깅 가능.

n8n에서 간단한 오류 워크플로우 구축 방법

오류 워크플로우 구축 시 오류 트리거를 먼저 추가.

오류 정보를 슬랙 메시지로 전송하는 간단한 오류 워크플로우 예시.

오류 발생 시 어떤 워크플로우에 오류가 있는지 즉시 알 수 있도록 설정.

워크플로우 오류 발생 시 해당 실행 정보가 포함된 메시지를 '오류' 채널에서 받도록 설정.

기존 워크플로우 정리 및 잠재적 오류 처리

기존 워크플로우를 정리하고 스위치 노드를 사용하여 명확성을 높임.

이메일 유효성 검사 및 이벤트 유형 확인을 통한 잠재적 오류 처리.

이메일 유효성 검사를 위한 기본적인 방법(예: @ 기호 포함 여부 확인).

유효하지 않은 이메일의 경우 중지 및 오류 노드를 추가하여 오류 메시지 표시.

유효하지 않은 이벤트 유형에 대한 처리 방법.

중지 및 오류 워크플로우 설정 및 동작 유형 선택

오류 발생 시 워크플로우 중지 여부 또는 계속 여부 설정 가능.

워크플로우가 계속되는 것을 막지 않는 에지 케이스 처리 시 계속 또는 오류 출력 사용 가능.

이 설정은 중지/오류 워크플로우 및 일반 노드 모두에 대해 노드별로 구성 가능.

n8n 초급 과정 다음 비디오 안내