見出し画像

n8nでエラー発生時だけSlack通知する｜Error Workflow実践【2026年版】

けいすけ

n8nでワークフローを作っていると、

「昨日から自動処理が止まっていた」
「APIエラーが出ていたのに気づかなかった」
「毎朝動くはずの処理が失敗していた」
「エラーが起きたときだけSlackに通知したい」

ということがあります。

ワークフローを毎日n8nの管理画面で確認するのは現実的ではありません。

そこで使えるのが、n8nの Error Workflow です。

Error Workflowを設定すると、別のワークフローで実行エラーが発生したときに専用のワークフローを起動できます。n8n公式では、Error Triggerを先頭にしたワークフローを作成し、監視対象ワークフローのSettingsからError Workflowとして指定する方法が案内されています。

この記事では、

n8nのワークフローが失敗したときだけSlackへエラー通知を送る

仕組みを作ります。

この記事で作るもの

最終的には、

通常のn8nワークフロー
        ↓
      実行
        ↓
   正常終了 → 何もしない
        ↓
      エラー
        ↓
   Error Workflow
        ↓
     Slack
        ↓
🚨 ワークフローでエラーが発生しました

という構成にします。

Slackには、

  • ワークフロー名

  • エラーメッセージ

  • エラーになったNode

  • Execution ID

  • n8nのExecution画面へのリンク

などを通知します。

これならSlack通知を見た時点で、

「どのワークフローで何が起きたか」

をある程度判断できます。

Error Workflowとは？

n8nでは、通常のワークフローとは別に、

エラー処理専用ワークフロー

を設定できます。

公式ドキュメントでは、Error Workflowは必ず、

Error Trigger

から始めます。

監視対象ワークフローで実行エラーが発生すると、

通常ワークフロー
↓
失敗
↓
Error Trigger
↓
Slack

のようにError Workflowが起動します。

Nodeごとの「On Error」とは別物

n8nにはNode単位でも、

On Error

という設定があります。

現在のn8nではNodeのエラー時動作として、

  • Stop Workflow

  • Continue

  • Continue using error output

などを指定できます。

これは、

そのNodeでエラーが発生したあと、ワークフローをどう動かすか

を決めるものです。

一方、今回使うError Workflowは、

ワークフロー自体が失敗したことを検知して別ワークフローを起動する

仕組みです。

用途が違います。

今回の構成

今回は2つのワークフローを作ります。

① 本来やりたい処理
Daily Data Sync

② エラー通知専用
Error Notification to Slack

たとえば①で、

Schedule Trigger
↓
HTTP Request
↓
Google Sheets

という処理が動いているとします。

HTTP Requestなどでエラーになったら、

②の、

Error Trigger
↓
Slack

を起動します。

Error Workflowを作成する

まず新しいワークフローを作ります。

名前は分かりやすく、

Error Notification to Slack

などにします。

n8n公式でも、Error Triggerを先頭Nodeにした新しいワークフローを作り、保存する手順が案内されています。

Error Triggerを追加する

Node追加画面で、

Error Trigger

を検索します。

追加すると、

Error Trigger

だけのワークフローになります。

Error Triggerには、通常のWebhookやSchedule Triggerのような細かい実行条件はありません。

紐付けられたワークフローが失敗したとき

に起動します。

Error Triggerから受け取れる情報

Error Workflowが起動すると、失敗したワークフローに関する情報が渡されます。

公式ドキュメントではExecutionやWorkflowに関する情報をError Triggerから参照できます。Execution IDは、そのExecutionがデータベースへ保存されている場合に利用できます。

実際には、

workflow
execution

などのデータを使って通知文を作ります。

まずはError Triggerの出力を確認すると、

「どの値をSlackへ送りたいか」

が分かりやすいです。

Slack Nodeを追加する

Error Triggerの次に、

Slack

Nodeを追加します。

n8nにはSlack用のBuilt-in Nodeがあり、メッセージ送信などの操作に対応しています。

構成は、

Error Trigger
↓
Slack

だけです。

かなりシンプルです。

Slack Credentialsを設定する

Slack Nodeを利用するには、n8nとSlackを認証する必要があります。

n8n公式にはSlack Credentialsの設定手順が用意されており、Slack Appを作成してOAuth Callback URLなどを設定する方法が案内されています。

Slack Nodeを開き、

Credential to connect with

からSlack Credentialを追加します。

利用しているn8n環境や認証方法に合わせて設定してください。

Slackの送信先Channelを決める

エラー通知専用Channelを作っておくと管理しやすいです。

たとえば、

#n8n-errors
#system-alerts
#automation-errors

などです。

通常の業務Channelへ大量にエラー通知を流すより、

システム通知専用Channel

へまとめると見やすくなります。

Slack Nodeを設定する

Slack Nodeでは、

Resource
Message

を選び、

メッセージ送信操作を設定します。

送信先Channelとして、

#n8n-errors

などを指定します。

n8nのSlack Nodeはメッセージ送信を含むSlack操作をBuilt-inで提供しています。

まずは固定メッセージで動作確認する

最初はいきなり複雑なExpressionを書かず、

🚨 n8nでエラーが発生しました

のような固定メッセージを設定します。

Slack CredentialとChannel設定が正しければ、Slack Node単体の確認がしやすくなります。

エラー情報をSlack本文に入れる

次にError Triggerから受け取った値をSlackメッセージへ入れます。

例として、

🚨 n8n Workflow Error

Workflow:
{{ $json.workflow.name }}

Error:
{{ $json.execution.error.message }}

Last Node:
{{ $json.execution.lastNodeExecuted }}

Execution ID:
{{ $json.execution.id }}

Execution:
{{ $json.execution.url }}

のような通知を作ります。

利用できるフィールドは、エラーの発生場所やExecution保存設定などによって異なる場合があります。特にexecution.idはExecutionがデータベースへ保存されている場合に利用できます。

そのため、実環境では一度Error Triggerの出力を確認してからExpressionを設定するのがおすすめです。

通知イメージ

Slackでは、たとえば、

🚨 n8n Workflow Error

Workflow:
Daily Customer Sync

Error:
Request failed with status code 500

Last Node:
Get Customers API

Execution ID:
18425

Execution:
https://n8n.example.com/execution/18425

のように表示させます。

これならSlackを見ただけで、

どのワークフロー
どのNode
どんなエラー

なのかがかなり分かります。

Execution URLは特に入れておく

エラー通知に、

Execution URL

を入れておくと便利です。

Slack通知
↓
リンクをクリック
↓
該当Executionをn8nで確認

という流れにできます。

エラーの詳細確認までの手順を短くできます。

Error Workflowを保存する

Slack Nodeまで設定したら、

Error Notification to Slack

を保存します。

これだけではまだ通常ワークフローとは繋がっていません。

監視したいワークフローを開く

次に、

エラーを監視したい元のワークフロー

を開きます。

たとえば、

Daily Customer Sync

です。

Workflow Settingsを開く

ワークフローのSettingsを開きます。

現在のn8nではWorkflow Settingsに、

Error Workflow

という設定があります。

ここで、失敗時に起動するワークフローを指定できます。

Error Workflowを指定する

Error Workflowに、

Error Notification to Slack

を指定します。

これで、

Daily Customer Sync
↓
エラー
↓
Error Notification to Slack
↓
Slack

が繋がります。

n8n公式では同じError Workflowを複数のワークフローから利用することもできます。

1個のError Workflowを共通化できる

これはかなり便利です。

たとえば、

Customer Sync
Invoice Sync
Daily Report
AI Workflow
Backup Workflow

という5つのワークフローがあったとしても、

全部にSlack Nodeを追加する必要はありません。

1つの、

Error Notification to Slack

を作って、

各Workflow Settingsから同じError Workflowを指定できます。公式にも、同一のError Workflowを複数ワークフローで利用できると記載されています。

Error Workflowを手動実行してもテストできない

ここがかなりハマりやすいポイントです。

Error Workflowを作ったあと、

Execute Workflow

を押して、

「何も起きない」

となることがあります。

これは正常です。

n8n公式では、

Error Triggerは自動実行されたワークフローが失敗した場合のみ起動し、手動実行ではError Workflowをテストできない

と明記されています。

ではどうやってテストする？

実際に、

自動実行されるテスト用ワークフローを失敗させます。

たとえば、

Schedule Trigger
↓
HTTP Request

を作ります。

HTTP Requestで、

存在しないURL

または、

意図的にエラーになるAPI

を呼びます。

そして、このWorkflow SettingsのError Workflowに、

Error Notification to Slack

を指定します。

テスト用WorkflowをPublishする

Error Workflowは自動実行時にテストする必要があるため、監視対象ワークフローを実際にProduction Executionとして動かします。手動ExecutionではError Triggerは発火しません。

現在のn8nでは編集内容を保存したうえで、本番実行させるワークフローをPublishして利用します。

Schedule Triggerで1回エラーを起こす

テスト中だけ短い間隔でSchedule Triggerを設定し、

Schedule Trigger
↓
失敗するHTTP Request

を自動実行します。

失敗すると、

Error Notification to Slack

が起動し、

Slackへ通知されるはずです。

確認できたらテスト用Workflowは停止するか削除します。

Slack通知が来たら確認すること

Slack通知が届いたら、

  • Workflow名

  • Error Message

  • Last Node

  • Execution ID

  • Execution URL

が想定どおり表示されているか確認します。

Execution URLをクリックして、実際の失敗Executionへ移動できるかも確認します。

Execution IDが表示されない場合

Error Triggerのexecution.idは、Executionがn8nのデータベースへ保存されている必要があります。

Workflow Settingsやn8n全体のExecution保存設定によっては、期待した情報を取得できない場合があります。

n8nではWorkflow Settingsや環境変数によってExecutionデータの保存方法を変更できます。

エラー調査でExecution IDを使いたい場合は、失敗Executionの保存設定も確認してください。

エラー通知用Workflow自身が失敗したら？

たとえば、

Error Trigger
↓
Slack

のSlack Credentialが切れていたら、

エラー通知自体も失敗

します。

そのため、Error Workflowを作ったら、

「通知用Workflowはできるだけ単純にする」

のがおすすめです。

今回のように、

Error Trigger
↓
Slack

程度にしておくと、障害ポイントを減らせます。

Slackが落ちている場合は通知できない

当然ですが、

エラー通知先そのものが利用できない場合、

Slackへ通知できません。

より重要なシステムなら、

Slack
+
Email
Slack
+
Discord

など複数経路を検討する方法もあります。

ただ、最初から複雑にする必要はありません。

まずはSlack通知だけでも、

何も監視していない状態

より大きく改善できます。

すべてのエラーを通知すると多すぎる場合

ワークフローによっては、

一時的なAPIエラー
↓
数秒後には成功

というケースがあります。

そのたびSlack通知すると、

通知が多すぎて誰も見なくなる

ことがあります。

その場合は、

Retry
↓
それでも失敗
↓
Error Workflow
↓
Slack

という設計を検討します。

たとえばHTTP Request Nodeでは、Node SettingsからRetry on Failを有効にし、最大試行回数などを設定できます。

RetryとError Workflowを組み合わせる

たとえば、

HTTP Request
Retry on Fail
Max Tries: 3

としておけば、

1回目失敗
↓
Retry
↓
2回目失敗
↓
Retry
↓
3回目失敗
↓
Workflow Error
↓
Slack通知

という形にできます。

こうすると、

一時的な通信エラーでは通知せず、本当に失敗した場合だけ通知

しやすくなります。

NodeをContinueにしているとError Workflowが動かない場合がある

Nodeの、

On Error

を、

Continue

などにしている場合、

Nodeでエラーが起きてもWorkflow全体を失敗として停止させず、後続処理へ進める設定になります。現在のn8nではNodeごとにエラー後の動作を設定できます。

そのため、

「エラーが出たのにError Workflowが動かない」

場合は、

Node側でエラーを握りつぶしていないか

も確認します。

エラー通知に環境名を入れる

DevelopmentとProductionで同じSlack Channelを使う場合、

通知に環境名を入れると分かりやすくなります。

たとえば、

🚨 [PRODUCTION] n8n Workflow Error
⚠️ [STAGING] n8n Workflow Error

などです。

本番エラーを見落としにくくなります。

Workflow名は分かりやすくする

Error Workflowを使うと、Slack通知でWorkflow名を見る機会が増えます。

そのため、

Workflow 12
Copy of Workflow
Test

より、

Daily Customer Sync
Invoice Notification
Weekly Sales Report

のような名前にしておいたほうが、エラー時に判断しやすくなります。

Slack通知テンプレート例

最初はこの程度で十分です。

🚨 n8n Workflow Error

Workflow:
{{ $json.workflow.name }}

Node:
{{ $json.execution.lastNodeExecuted }}

Error:
{{ $json.execution.error.message }}

Execution ID:
{{ $json.execution.id }}

Execution URL:
{{ $json.execution.url }}

実際に利用できるプロパティはError Triggerの出力内容によって確認してください。Error Triggerでは失敗したWorkflowやExecutionに関する情報を受け取れます。

もう少し見やすくする例

🚨 *n8n Workflow Error*

*Workflow*
{{ $json.workflow.name }}

*Failed Node*
{{ $json.execution.lastNodeExecuted }}

*Error*
{{ $json.execution.error.message }}

*Execution*
{{ $json.execution.url }}

Slack側で見やすい書式にすると、

スマホから確認するときにも分かりやすくなります。

エラーメッセージに機密情報が含まれていないか確認する

これは本番利用では重要です。

Nodeによっては、エラー情報の中に、

  • APIのレスポンス

  • URL

  • Query Parameter

  • ユーザー情報

  • 外部サービスから返された値

などが含まれることがあります。

そのままSlackへ送る前に、

どの情報を通知してよいか

確認しましょう。

特に共有Channelの場合、

「エラーだから全部貼る」

ではなく、

Workflow
Node
Error概要
Execution URL

程度に留めて、詳細はn8n管理画面で確認する設計もありです。

Slack Credentialの権限も必要最小限にする

n8nからSlackへ接続する場合はSlack AppやCredentialを利用します。n8n公式にはSlack Credentialsの設定方法が用意されています。

エラー通知しか使わないのであれば、

必要以上の権限をSlack Appへ与えない

ようにします。

Error Workflowは複数作ってもいい

全ワークフローで同じ通知にする必要はありません。

たとえば、

重要システム
↓
#critical-alerts

通常の自動化
↓
#n8n-errors

個人用Workflow
↓
自分へのDM

のようにError Workflowを分けても構いません。

一方で、同じError Workflowを複数ワークフローから共有することもn8n公式でサポートされています。

まずは共通Error Workflowを1個作るのがおすすめ

最初は、

Global Error Notification

のような共通Workflowを1つ作って、

重要なWorkflowから順番に紐付けるのが分かりやすいです。

構成は、

Error Trigger
↓
Slack

だけ。

これなら、

20個Workflowがあっても、

通知処理を20回作る必要はありません。

本番導入チェックリスト

Error Workflow

  • Error Workflowを新規作成した

  • Error Triggerを先頭Nodeにした

  • Slack Nodeを追加した

  • Workflowを保存した

Slack

  • Slack Credentialを設定した

  • 通知先Channelを決めた

  • 固定メッセージの送信を確認した

  • Workflow名を通知している

  • Error Messageを通知している

  • Execution URLを必要に応じて通知している

監視対象Workflow

  • Workflow Settingsを開いた

  • Error Workflowを指定した

  • NodeのOn Error設定を確認した

  • 必要ならRetry on Failを設定した

テスト

  • 手動ExecutionではError Triggerが発火しないことを理解した

  • 自動実行されるテストWorkflowを用意した

  • 意図的にエラーを発生させた

  • Slackへ通知された

  • Execution画面まで確認できた

本番運用

  • エラー通知に機密情報を含めていない

  • Slack Appへ必要以上の権限を与えていない

  • 一時的なエラーで通知が大量発生しない

  • 本当に確認するChannelへ通知している

まとめ：n8nのエラー監視はError Workflowを1つ作ればいい

n8nで、

「ワークフローが失敗したらSlackへ通知したい」

場合、各ワークフローへSlack Nodeを追加する必要はありません。

基本構成は、

Error Trigger
↓
Slack

だけです。

このワークフローを、

Error Notification to Slack

として作成。

次に監視したいワークフローのSettingsから、

Error Workflow

へ指定します。n8n公式でもこの方法が案内されています。

さらに、同じError Workflowを複数の通常ワークフローから共有できます。

そのため、

Workflow A ─┐
Workflow B ─┤
Workflow C ─┼→ Error Workflow → Slack
Workflow D ─┤
Workflow E ─┘

という共通エラー通知基盤を簡単に作れます。

ただし、重要なのがテスト方法です。

2026年8月現在、Error Triggerは、

手動実行では発火しません。

自動実行されたWorkflowがエラーになったときだけError Workflowが起動するため、動作確認ではSchedule TriggerやWebhookなどを使ったProduction Executionで意図的に失敗させる必要があります。

また、

Retry on Fail
↓
それでも失敗
↓
Error Workflow
↓
Slack

という形にすると、一時的な通信エラーで通知が大量に飛ぶのを抑えやすくなります。HTTP Request NodeなどではRetry on Failを設定できます。

まずは、

「n8nの自動処理が止まったことに、翌日まで気づかない」

状態をなくす。

そのための最初の監視として、Error Workflow + Slack通知はかなりシンプルに導入できます。