自動化が止まっていたことに、翌日の未登録データを見て気づいた。n8nのエラーワークフローを使うと、実行失敗をきっかけに別の処理を動かし、担当者へ知らせる構成を作れます。毎回管理画面を開かなくても、調査を始めるきっかけを受け取れます。
ただし、通知を作ることと、失敗を復旧することは別です。通知には調べる手掛かりを入れ、再実行してよいかは元の処理と登録先を見て判断します。この記事では、Error Triggerの設定と、通知が来ない場合の確認を整理します。
通知専用のワークフローを用意する
エラー処理用の新しいワークフローを作り、先頭にError Triggerを置いて保存します。次に監視したい元のワークフローの設定で、Error workflowとしてそのワークフローを指定します。通知用を作っただけでは、別の既存処理すべてに自動で紐付くわけではありません。
同じエラーワークフローを複数のワークフローで使うこともできます。その場合は、通知文に元のワークフロー名や識別できる情報を入れます。「エラーが発生しました」だけでは、どの業務を確認すべきか分からず、通知を共通化した意味が薄れます。
現行の公式では、Error Triggerを使うワークフロー自体を公開する必要はないと案内されています。元の処理の自動実行と、エラー処理用ワークフローの設定を混同しないようにします。利用中の版で設定項目を確認し、古い画面説明だけを頼りにしないでください。
手動実行だけでは通知の試験にならない
Error Triggerは、自動実行のワークフローが失敗したときに動きます。公式では、手動実行でエラーワークフローをテストできないとされています。エディターの実行ボタンで意図的に失敗させ、通知が来ないことだけを見て設定不良と判断しないでください。
試験は本番の顧客データを使わず、管理できるテスト用のワークフローと入力で行います。自動実行の入口から起動し、意図した地点で失敗する構成を使って、Error Triggerから通知先まで届くかを見ます。元の本番処理を壊して確かめる必要はありません。
Stop And Errorを使うと、指定した条件で実行を失敗として扱う構成も作れます。例えば必要な識別番号がない場合を、確認が必要な状態として止める設計です。ただし何を失敗とみなすかは業務の判断なので、単なる対象外データまで一律に異常通知しないよう整理します。
通知には調査を始められる情報を入れる
通知文には、どのワークフローで、どの処理が、どんなエラーで止まったかを入れます。実行URLやIDが得られる場合は、それも手掛かりになります。担当者が別の画面から検索し直さなくても、失敗した一回へ戻れる形を目指します。
ただし、すべての失敗で同じ項目があるわけではありません。公式では、実行IDとURLには実行が保存されていることが必要で、元のトリガーノードのエラーでは得られない場合があると説明されています。必ず存在する前提で文面を作ると、通知側で別のエラーになる原因になります。
元のトリガーで失敗した場合は、通常の実行途中のエラーとはデータの形も違います。通知を作る際は、成功した試験一例の項目だけを固定で参照せず、欠けている場合の表示を決めます。「実行URLなし、トリガー段階を確認」のように、次の行動が分かる書き方が有効です。
再試行だったことを示す情報も、常に付くわけではありません。ある場合は元の失敗と対応させ、同じ事故の通知が増えているのか、新しい失敗が起きたのかを分けます。通知数だけを障害件数として数えないようにしましょう。
エラー全文をそのまま広い場所へ送らない
外部サービスのエラーには、入力した文面やIDなどが含まれる可能性があります。通知を誰が読むのかを先に決め、調査に必要な情報だけに絞ります。顧客の相談本文や認証情報を、誰でも見られるチャンネルへ丸ごと転載する構成は避けてください。
まず概要を通知し、詳細は権限のある実行履歴で見る形にすると、必要な人だけが調査を進めやすくなります。通知先の名前だけでなく、参加者や閲覧範囲も確認します。引き継ぎで担当者が変わった際も、古い個人宛てに通知が残らないようにします。
通知のタイトルには、業務名と対応の要否が分かる言葉を使います。一時的な失敗を毎回緊急扱いにすると、重要な通知も見逃されやすくなります。何をすぐ確認し、何を定期点検へ回すかを決め、必要以上に長いエラー文を並べないようにします。
届かなかったときの確認順
最初に、元のワークフローが本当に失敗したのかを実行履歴で見ます。条件に合わず正常終了した場合や、期待したデータがそもそも入っていない場合は、エラー通知が来ないことがあります。「結果がない」と「実行失敗」は分けて調べてください。
次に、元の設定で対象のエラーワークフローが選ばれているかを見ます。コピーしたワークフローや新しく作った処理では、紐付けを確認します。その後、エラーワークフロー側の実行と通知モジュールを追い、受け取った値と通知先を見ます。
通知先サービスの接続切れや権限不足があれば、元のエラーとは別に修正します。通知処理が動いた事実だけでなく、実際に受信した本文まで確認してください。テスト用の通知先で届いた後、本番の担当者へ渡す設定が正しいかも見直します。
通知後の対応を一つの手順にする
通知を受けたら、まずどこまで処理済みかを確かめます。レコードの作成には成功し、その後の通知だけ失敗していたなら、最初から再実行すると二重登録になるかもしれません。失敗したノードと外部サービスの実状態を照合してから復旧します。
対応記録には元の実行、原因、変更点、再実行の範囲、復旧後の確認を残します。「通知を受け取れた」と「業務データがそろった」を別に記録することで、通知機能を付けただけで復旧完了とする取り違えを防げます。
最後に、通知を受ける担当者が不在のときも含めて、確認する場所と役割を共有します。エラー処理を作る目的は、赤い表示を別の場所へ移すことではありません。誰かが失敗した一回を調べ、必要な処理を回復できるところまでを運用として整えましょう。
確認日：2026年10月16日。設定とデータ項目はn8n公式 Error Triggerとエラー処理の公式解説を確認。通知設計と復旧記録は運用上の提案です。
コメント