n8n のエラー通知は、手動実行では飛ばない

前の記事で「Error Trigger との関係は検証していません」と書きました。 その宿題です。

n8n には、ワークフローが失敗したときに別の処理を走らせる仕組みがあります。 Slack に通知する、ログに残す、といった用途です。設定自体は簡単なのですが、 「設定したのに通知が来ない」が起きやすい落とし穴があります。

実際に失敗するワークフローを作って、発火する条件と、受け取り側に届くデータを確かめました。

手動実行では発火しない

先に結論です。エディタで「Execute workflow」を押して失敗しても、エラー通知は飛びません。

同じワークフローを、手動実行と本番実行（Publish 済みの Webhook を叩く）で それぞれ失敗させ、受け取り側の実行が増えるか数えました。

実行のしかた	失敗側の結果	受け取り側の実行
手動実行	error	0件（発火せず）
本番実行（Webhook）	error	1件（発火）

これは実務でかなり危ないところです。設定した直後に手動で失敗させて「通知が来ないな、 設定が間違っているのかな」と設定をいじり直す、という時間の使い方をしがちです。 設定は正しくても、手動実行である限り通知は来ません。

確かめたいなら、Publish してから本番の経路で失敗させてください。 Webhook なら URL を叩く、Schedule Trigger なら実行時刻を待つ、ということです。

受け取り側を Publish していないと、指定すらできない

もう1つ、順番の問題があります。

エラーワークフローを指定しようとしたら、こう言われて弾かれました。

Error workflow 'エラー受け取り' has no published version,
so n8n cannot run it when this workflow fails.
Publish that workflow first, then set it as the error workflow.

受け取り側を先に Publish しないと、呼び出し側の設定に出てきません。 作って保存しただけの 下書き状態では指定できないということです。順番は「受け取り側を作る → Publish → 呼び出し側で指定」になります。

設定する場所

ワークフローの ... メニューから Settings を開きます。項目名はこれです。

Error Workflow (to notify when this one errors) という長い名前の欄です。 ノードごとの On Error とは別物で、ワークフロー全体に1つの設定です。

同じ画面に Save failed production executions や Save manual executions も並んでいます。 どちらも既定は Default - Save でした。

Error Trigger に届くデータ

受け取り側の Error Trigger に何が渡るのかを、Code ノードでそのまま出力して確認しました。

{
  "execution": {
    "id": "38",
    "url": "http://localhost:5678/workflow/etDSmNUVHlOLQ3Rp/executions/38",
    "error": {
      "message": "Authorization failed - please check your credentials",
      "httpCode": "401",
      "description": "Unauthorized",
      "node": { "name": "必ず失敗する", "type": "n8n-nodes-base.httpRequest" }
    },
    "lastNodeExecuted": "必ず失敗する",
    "mode": "webhook"
  },
  "workflow": {
    "id": "etDSmNUVHlOLQ3Rp",
    "name": "エラー発生"
  }
}

通知を作るなら、使うのはこのあたりです。

使うもの	中身
workflow.name	どのワークフローが落ちたか
execution.lastNodeExecuted	どのノードで落ちたか
execution.error.message	エラーの文言
execution.url	失敗した実行そのものへのリンク

execution.url が入っているのが実用上いちばん効きます。 Slack のメッセージにこれを貼れば、 通知から1クリックで失敗した実行の中身を開けます。n8n を開いて実行履歴を探す手間が消えます。

mode には起動のしかたが入ります。今回は webhook でした。

置き方は2通りある

Error Trigger の置き場所には2つのやり方があります。

1. 別のワークフローに置く（上で説明した方法）。Error Workflow 欄で指定する
2. 同じワークフローの中に置く。Error Workflow の指定は不要で、Error Trigger ノードを canvas に足すだけで、そのワークフローが失敗したときに勝手に動く

2番は設定がいらないぶん手軽ですが、実行履歴の見え方が変わります。

同居させると、失敗1回で実行が2件になる

同じワークフローに Error Trigger を置いて失敗させたところ、実行が2件記録されました。

一覧の 10:43:37 を見てください。同じ時刻に2件あります。

• Error in 19ms — 本体の実行（Webhook で起動して失敗した方）
• Succeeded in 51ms — Error Trigger から始まった実行（通知処理は成功した）

紛らわしいのは、エラー処理が成功すると Succeeded と表示されることです。 一覧を眺めて「成功している」と読むと、実際には失敗が起きています。

そしてもう1つ。実行履歴の件数が実質2倍になります。 失敗が多いワークフローでは、 履歴が読みにくくなります。

両方設定すると、別ワークフロー側が勝つ

「同居の Error Trigger」と「Error Workflow の指定」を両方設定したらどうなるか。 これも確かめました。

同じワークフローに両方を設定して失敗させたところ、別ワークフロー側だけが動き、 同居の Error Trigger は発火しませんでした。

上のスクリーンショットがそのまま証拠になっています。10:44:07 の行を見てください。 Error が1件だけで、対になる Succeeded がありません。 同居の Error Trigger が 動かなかったからです。キャンバス上でも下段の Error Trigger 側は灰色のまま、 一度も実行されていません。

Error Workflow の指定がある限り、同じワークフロー内の Error Trigger は無視されます。 両方置いても二重に通知が来ることはない代わりに、同居側を置いた意味がなくなります。 どちらか一方に決めてください。

どちらを選ぶか

検証した範囲では、こう整理できます。

• 通知の中身を共通化したい（複数のワークフローで同じ Slack 通知を使う） → 別ワークフロー。1つ作って各ワークフローから指定すれば、直すときも1箇所で済みます
• そのワークフロー固有の後始末をしたい（失敗したレコードだけ別テーブルに書く、など） → 同居。ただし実行履歴が2倍になることは織り込むこと

迷うなら別ワークフローを勧めます。指定を外すだけで切り離せるので、あとから変えやすいためです。

検証していないこと

• Schedule Trigger での本番実行は試していません。 本番実行の例として使ったのは Webhook 1パターンだけです。定時実行でも同じはずですが、確認はしていません
• 通知を実際に送るところまでは作っていません。 Error Trigger が受け取るデータを Code ノードで出力して中身を見ただけで、Slack やメールには繋いでいません
• 失敗のさせ方は 401（認証エラー）1パターンです
• Save failed production executions を Do not save にしたときにエラーワークフローが 発火するかは確認していません。履歴を保存しない設定と通知が連動するのかどうかは、 別途確かめる必要があります

---

「設定したのに動かない」の原因が設定ミスではなく実行のしかただった、というのが 今回いちばんの収穫でした。

• ノードごとのエラー設定は n8n でエラーが起きたとき、後続ノードには何が届くのか に書きました
• Publish と本番実行の違いは n8n 用語集 にまとめています
• 失敗しやすい HTTP まわりの設定は HTTP Request ノードの使い方 にあります