n8nのエラーワークフローで失敗を担当者に知らせる設定手順

通知文に入れる項目リスト

先に、通知で何を伝えるかを決めておくと、ノードの設定で迷いません。Error Triggerが受け取るデータには、実行ID、実行のURL、エラーメッセージ、最後に実行されたノード名、ワークフローのIDと名前などが含まれます(公式ドキュメントに載っている出力例による)。これを担当者の行動に合わせて並べると次のとおりです。

• 必須、項目：ワークフロー名、取り出し元(公式の出力例の項目)：workflow.name、受け取った人の行動：どの業務が止まったか分かる
• 必須、項目：失敗したノード名、取り出し元(公式の出力例の項目)：execution.lastNodeExecuted、受け取った人の行動：原因の当たりを付ける
• 必須、項目：エラーメッセージ(短縮)、取り出し元(公式の出力例の項目)：execution.error.message、受け取った人の行動：認証切れか、入力不備かを判断する
• 必須、項目：実行ページのURL、取り出し元(公式の出力例の項目)：execution.url、受け取った人の行動：1クリックで失敗した実行を開く
• 推奨、項目：実行ID、取り出し元(公式の出力例の項目)：execution.id、受け取った人の行動：問い合わせや記録で特定する
• 推奨、項目：実行モード、取り出し元(公式の出力例の項目)：execution.mode、受け取った人の行動：実行の起動方法を確認する
• 推奨、項目：担当者名・一次対応先、取り出し元(公式の出力例の項目)：通知ノード側に固定文で書く、受け取った人の行動：誰が見るべきか迷わせない
• 任意、項目：影響の説明(例:「請求書が未作成の可能性」)、取り出し元(公式の出力例の項目)：固定文で書く、受け取った人の行動：緊急度を判断する

注意点があります。公式ドキュメントによると、トリガーノード自体でエラーが起きた場合は、出力の形が変わり、trigger.error(message、name、causeなど)にエラー情報が入ります。workflowは残りますが、実行URLや最後のノード名は取れない場合があります。また、execution.idとexecution.urlは実行がデータベースに保存された場合だけ得られるため、取得できないときは省略する文面にしてください。

手順1:エラーワークフローを作る

1. n8nで新しいワークフローを作成します。
2. 最初のノードとして「Error Trigger」を追加します。
3. ワークフローに「Error Handler」のような分かりやすい名前を付けます。複数作る予定なら、「Error Handler 経理用」のように宛先が分かる名前にします。

公式ドキュメントでは、このワークフローを公開(有効化)する必要はないとされています。ただし、まず手順1〜2を済ませて保存してください。保存前だと、次の紐付けの選択肢に出てきません。

手順2:通知ノードをつなぐ

Error Triggerの後ろに、普段使っている通知手段のノード(SlackやメールのSend Emailなど)を1つつなぎます。最初は1か所だけにして、届くことを確認してから増やすほうが安全です。

通知文の本文には、n8nの式で先ほどの項目を差し込みます。以下は説明用の例です。公式の出力例の項目名から組み立てたもので、私の環境で実行して確認したものではありません。実際の画面でErrorTriggerの出力を見て、項目名が合っているか確かめてから使ってください。

【n8n失敗】{{ $json.workflow.name }}
失敗したノード: {{ $json.execution.lastNodeExecuted }}
内容: {{ String($json.execution.error.message).slice(0, 200) }}
実行ページ: {{ $json.execution.url }}
実行ID: {{ $json.execution.id }}
一次対応: 山田(不在時は佐藤)
影響: 請求書の自動作成が止まっています

「一次対応」と「影響」は固定文です。ここは自分の業務に合わせて書き換えてください。

トリガー自体が失敗したとき用の文面

トリガーノードのエラーではexecutionが来ない形があるため、上の式をそのまま使うと値が空になったり、式がエラーになったりする可能性があります。対策として、IFノードでtriggerの有無を判定して2系統に分け、トリガー失敗側には次のような短い文面を使う方法が考えられます(説明用の例、未検証)。

【n8n失敗・トリガー】{{ $json.workflow.name }}
内容: {{ String($json.trigger.error.message).slice(0, 200) }}
n8nで該当ワークフローを開いて、トリガーの設定を確認してください。

トリガー側ではURLが取れないため、「n8nを開いて確認する」という行動を文面に書いておくと迷いません。

手順3:監視したいワークフローに紐付ける

エラーワークフローは、作っただけでは動きません。監視したいワークフローごとに指定します。

1. 監視したいワークフロー(例:請求書作成)を開きます。
2. 右上のメニューから「Options > Settings」(公式の表記。画面では「Settings」の場合もあります)を開きます。
3. 「Error workflow」の項目で、手順1で作った「Error Handler」を選びます。
4. 保存します。

公式ドキュメントは、ワークフローごとに設定でき、そのワークフローの実行が失敗したときに動く、と説明しています。裏を返せば、監視したいワークフローの数だけこの設定が必要です。新しい自動化を作ったら、この設定をチェックリストに入れておくと漏れを防げます。複数のワークフローで同じエラーワークフローを共有でき、通知文にワークフロー名が入るため、どれが失敗したか区別できます。

手順4:失敗を意図的に起こしてテストする

ここで落とし穴があります。公式ドキュメントには、手動でワークフローを実行してもエラーワークフローはテストできない、と明記されています。画面の「Execute workflow」ボタンで失敗させても、通知は来ません。

テストの進め方として、次の方法が考えられます(編集上の提案で、私の環境で実行したものではありません)。

1. 試験用のワークフローを新規に作ります。トリガーは、スケジュールやWebhookなど自動で起動できるものにします。
2. 後ろに「Stop And Error」ノードをつなぎます。公式ドキュメントでは、このノードは意図的に実行を失敗させ、エラーワークフローを起動するために使えるとされています。エラーメッセージには「テスト用の失敗です」など、本番の障害と区別できる文を書きます。
3. 試験用ワークフローの設定で「Error workflow」に手順1のものを指定します。
4. スケジュールを使う場合は、Schedule Triggerの公式ドキュメントに従い、試験用ワークフローを保存して公開します。自動で起動する形で実行し、通知が届くか確認します。

確認するポイントは次の3つです。

• 通知が想定の宛先(チャンネルやメールアドレス)に届いたか
• 実行ページのURLを開くと、失敗した実行が表示されるか
• 文面の項目が空欄になっていないか

確認が終わったら、試験用ワークフローは削除するか、無効にしておきます。放置すると定期的に偽の失敗通知が飛びます。

運用で迷う点の判断表

• 担当者が複数いる、判断の目安：通知先はチャンネルなど共有の場所に1つ置き、文面に一次対応者を書く
• 業務ごとに宛先を変えたい、判断の目安：エラーワークフローを宛先ごとに分け、各ワークフローの設定で選ぶ
• 通知が多すぎて無視されそう、判断の目安：件名に「【n8n失敗】」を付けて絞り込みやすくし、重要度の低い自動化は別の宛先にする
• エラーメッセージが長い、判断の目安：先頭200字程度に切り、全文は実行ページで見る
• 新しいワークフローを作った、判断の目安：「Error workflow」の指定をチェックリストの最終項目にする

宛先を分けるか1つにするかは、チームの人数と業務の重要度で決めてください。最初は1本で始め、通知が混ざって困ってから分けても遅くありません。

設定後に見直すこと

エラーワークフロー自体も、通知ノードの認証切れなどで失敗する可能性があります。通知が来ないことは失敗が無いことの証明にはなりません。月に一度など決めて、試験用の失敗を起こして届くことを確かめる運用をおすすめします。通知ノードの認証情報が切れていないかも、このときに確認できます。