運用と乗り換え
n8nのエラー通知を設定する
n8nのError Workflowを設定し、稼働中のWorkflow失敗を通知してExecutionsから原因を調べる手順を整理します。
n8n公式2.x資料に基づくLevel A解説です。手動実行と自動実行のテスト条件を区別しています。
n8nで稼働中のWorkflowが失敗しても、誰もExecutionsを見ていなければ気づくのが遅れます。Error Triggerを先頭に置いた別Workflowを作成し、監視対象のWorkflow SettingsでError workflowへ指定すると、失敗情報をSlackやメールへ通知できます。手動実行で失敗させてもError Triggerの検証にはならないため、テスト方法を区別してください。
何を作るのか：監視対象と通知用Workflowは別
この構成には2本のWorkflowがあります。
通常Workflow（監視対象）：スケジュールやWebhookなどから自動実行し、業務処理を進めるWorkflow。
Error Workflow（通知用）：Error Triggerを先頭に置き、監視対象が失敗した際に渡される情報を受け取り、Slackやメールへ通知するWorkflow。
例えば、毎朝の集計Workflowが失敗したとき、通知用Workflowで「どのWorkflowが」「どのノード付近で」「どんなエラーで」止まったのかを知らせます。通知は障害の検知であって、原因の特定や復旧まで自動的に完了させるものではありません。
n8n公式は、同じError Workflowを複数の通常Workflowに割り当てられると案内しています。
1. Error Triggerを先頭に置く
新規Workflowを作り、最初のノードとしてError Triggerを追加します。名前は運用担当者が識別できるよう、例えば「Error Handler - Team Ops」とします。
次にSlackやメールなど通知用ノードをつなぎます。最初は閲覧者を限定したテストチャンネルを使ってください。エラーメッセージや実行データには、ワークフローによって顧客情報やAPI応答などが混ざる可能性があります。認証情報・個人情報・生の入力データを通知本文へ丸ごと転送しない構成にします。
通知では、少なくとも以下を識別できるようにします。
- Workflow名
- エラーメッセージ（機密情報が含まれない範囲）
- 最後に実行されたノード名（取得できる場合）
- ExecutionsへのURL（値が存在する場合）
- 調査担当者や運用先
これらは通知に含める項目の編集上の推奨であり、n8nの必須テンプレートではありません。
2. 監視対象のWorkflow Settingsへ指定する
通知WorkflowをSaveした後、監視したい通常Workflowを開きます。
- 監視対象WorkflowのOptions → Settingsを開きます。
- Error workflowから、作成した通知用Workflowを選択します。
- 設定をSaveします。
現行の公式Error Triggerページは、Error Triggerを含むWorkflowはPublish不要と明記しています。一方、通常WorkflowをスケジュールやWebhookで本番自動実行させるためのPublish状態は別の問題です。この2つを混同しないでください。
n8nのUI・Publishの仕様はバージョンにより変わり得るため、本稿公開時点では必ず公式Error Trigger・Error handling・Save and publishの記述を再照合します。
3. Error Triggerに何が渡されるか
失敗の種類によって、取得できるデータが違います。通常の実行中エラーでは、公式のサンプルにworkflow.name、workflow.id、execution.error.message、execution.lastNodeExecuted、execution.urlなどが示されています。
ただし、execution.id / execution.urlは常に存在するわけではありません。 公式は実行データがデータベースへ保存されている必要があり、通常WorkflowのTrigger nodeで実行開始前に起きたエラーの場合には取得できないと説明しています。また、Triggerの失敗では通常のexecutionとは異なるtrigger.error側のデータ構造が届く場合があります。
そのため、通知用Textに実行URLを必須項目として固定せず、値があるときだけURLを表示し、ないときはWorkflow名とエラー概要を使う構成を検討してください。空欄をそのまま公開チャンネルに流さないことも大切です。
4. 手動実行の失敗ではテストできない
ここがもっとも誤解しやすい点です。
n8n公式はError Triggerが、自動実行されたWorkflowが失敗した場合に動作すると明記しています。 EditorのExecute Workflowから手動実行して失敗させても、Error Triggerが発火しないことがあります。これは必ずしも設定ミスではありません。
試験では、実運用のデータを使わず、次のようにテスト専用のWorkflowを用意します。
- テスト用の通常Workflowを作る。
- 自動実行できるTrigger（例えばSchedule Trigger）を用いる。
- 後段にStop And Errorを置き、分かりやすい架空のエラーメッセージを設定する。
- テスト用通常WorkflowにError Workflowを割り当て、本番自動実行に必要な公開設定を確認する。
- 自動実行によって意図的に失敗させ、通知が届くかとExecutionsの記録を確認する。
- 確認後はテスト用Workflowの自動実行を停止し、不要な失敗通知を継続させない。
Stop And Errorは意図的にExecutionを失敗させ、エラー情報をError Workflowへ送るために使用できる公式ノードです。実際の業務Workflowに恒久的な失敗ノードを挿入しないようにしてください。
これは読者向けの安全な検証設計です。記事のためにFineInTheoryがn8nを実行したという報告ではありません。
5. 通知が来た後はExecutionsで原因を調べる
通知は「失敗した」ことを伝えます。原因を特定するときは監視対象WorkflowのExecutionsを開き、対象時刻の実行を選んで調べます。
- 失敗したノードとError Message
- 入力データが前段から渡っているか
- 資格情報の認証失敗なのか、取得データの形式が変わったのか
- 外部APIの応答やRate limitの有無
- 一時的な外部障害か、恒常的な設定不一致か
- 再実行すると二重書き込み・二重通知にならないか
n8n公式はExecutionsから過去の実行データをデバッグに利用できる機能を案内しています。ただし保存設定・権限によって確認可能な範囲が異なり得ます。URLがない＝エラーが起きていないではありません。Workflow名や時刻などから確認してください。
6. 通知が届かないときの確認表
| 状況 | まず確認すること | 誤解しやすい点 |
|---|---|---|
| 手動実行でエラーにしたが通知がない | 実行モード | 手動実行はError Triggerの検証にならない |
| 自動実行で失敗したのに通知がない | 監視対象のWorkflow SettingsのError workflow選択 | 別Workflowを作っただけでは自動でリンクされない |
| Error Workflowは動くがSlackに届かない | 通知ノードの設定と接続権限、エラー表示 | Error TriggerとSlack送信は別の処理 |
| Workflow名は表示されるが実行URLが空 | error payloadのデータ構造と実行保存設定 | Trigger node自体の失敗ではURLがない場合がある |
| 失敗したはずなのにError Workflowが動かない | 通常Workflowが本当に失敗ステータスか | ノード内のエラー処理で継続した実行とは区別する |
| テスト完了後も通知が続く | テストWorkflowのSchedule/公開状態 | 故意の失敗を常設しない |
上記は原因候補の整理です。各環境で発生した事実を報告するものではなく、ログと公式仕様を照合して切り分けます。
7. Error Workflowとノード単位のエラー処理は役割が違う
Error Workflowは、Workflowが失敗として扱われるときに通知する仕組みです。ノードごとの再試行やエラー出力に分岐させる処理とは設計目的が違います。
例えば、外部サービスの一時エラーをノード内で適切にリトライして成功した処理なら、Workflow全体が失敗したとは限りません。逆に重要な失敗を握り潰し、見かけ上成功とする設計だと、障害の検知から漏れるおそれがあります。何を「通知すべき失敗」とするかを先に決めてください。
また、通知だけで復旧するわけではないため、再試行の担当者、二重実行を避ける確認手順、Secretsやログ保存の権限も運用に含めます。
8. まだ調べますか？
Webhookを本番で受信できない段階ならn8n WebhookのTestとProductionが先です。そもそもn8nの運用形態を選ぶ段階ならn8nとはやn8n CloudとSelf-hostの比較を参照してください。
稼働後のWorkflowを監視する場合は、失敗を受け取るError Workflow → 関係者へ通知 → Executionsで原因調査 → 安全な復旧判断を一つの運用ルールとして決めることが重要です。