n8nエラーハンドリング入門｜止まらせない設定3つ

「n8nのワークフローを設定したのに、気づいたら止まってた…」

自動化ツールとして人気のn8nですが、エラーハンドリングをちゃんと設定していないと、ある日突然ワークフローが止まっていて気づかない、なんてことが起きます。

結論からいうと、「エラー出力の活用」「Retry設定」「エラーワークフロー通知」の3つを仕込むだけで、n8nの自動化はグッと安定します。

この記事では、はじめてn8nを触る方は基本編から、すでに動かしている方は応用編からどうぞ。

以下の順番で解説します。

そもそもn8nのエラーとは何か
デフォルトで何が起きるか
3種類のノードエラー設定の使い分け
Retry設定で自動リトライする方法
エラーワークフローでSlack通知を受け取る方法

n8nのエラーハンドリングとは？
デフォルトだとエラーでワークフロー全体が止まる
【基本編】ノードごとに選べる3つのエラー動作
【基本編】Retry on Failで一時エラーを自動リトライ
【応用編】エラーワークフローでSlack通知を受け取る
よくあるトラブルと対処法
まとめ

n8nのエラーハンドリングとは？

n8nは、複数のアプリやサービスを「ノード」でつないで自動化するツールです。

ノードとは、「Gmailからメールを取得する」「Slackに通知を送る」など、1つの処理の単位のこと。複数のノードをフローで結んで、自動化ワークフローを作ります。

エラーハンドリングとは、ノードで処理に失敗したときに、どう対応するかを設定することです。

たとえば外部APIへのリクエストが一時的にタイムアウトした場合、何も設定していないとワークフロー全体が止まります。でも適切に設定しておけば、自動でリトライしたり、エラーをSlackに通知したりできます。

デフォルトだとエラーでワークフロー全体が止まる

n8nのデフォルト動作は「エラーが起きたらそこで止める」です。

どのノードでも、設定を変えない限り「Stop and Error（止めてエラー扱い）」になっています。1つのノードが失敗すると、そのフロー全体の実行が止まります。

これが何を意味するかというと：

APIが一時的に落ちていただけなのに、ワークフローが止まる
エラーが起きたことに気づかず、何日も自動化が動いていなかった
ログを見ようとしても、どこで止まったか分からない

こういった状況を防ぐのが、これから紹介する3つの設定です。

【基本編】ノードごとに選べる3つのエラー動作

n8nの各ノードには、エラー時の動作を設定する項目があります。ノードをクリックして右パネルを開き、「Settings」タブから確認できます。

① Stop and Error（デフォルト）

エラーが起きた時点でワークフローを止めます。エラーログが残るので、後から「何が失敗したか」を確認できます。

向いてる場面：処理が絶対に成功しないと後続ステップが意味をなさない場合。データの取得に失敗したのに次の処理に進んでも、空のデータを処理するだけになるケースなどです。

② Continue (Using Error Output)

エラーが起きても止めずに、「エラー専用の出力ルート」に処理を流します。n8nのエラーハンドリングで最も活用頻度が高い設定です。

ノードに「エラー出力」というポートが追加され、そこから別のノードにつなげられます。「エラーが起きたらSlackに通知する」「エラー内容をスプレッドシートに記録する」といった処理を組み込めます。

向いてる場面：エラーが起きても後続の処理を続けたい場合や、エラー内容を記録・通知したい場合。

③ Continue (Ignoring Error)

エラーを完全に無視して、次のノードに処理を渡します。エラーが起きたことさえ記録しません。

向いてる場面：オプション的な処理でエラーになっても問題ない場合。たとえば「画像の取得に失敗してもテキスト処理は続ける」など。

ただし、これを多用すると「なぜかデータがおかしい」という状況に気づきにくくなります。使う場面は慎重に選びましょう。

【基本編】Retry on Failで一時エラーを自動リトライ

n8nには「Retry on Fail（失敗したらリトライ）」という便利な設定もあります。

同じく「Settings」タブの中にあり、以下を設定できます：

Retry on Fail：オン/オフ
Max Tries：最大リトライ回数（デフォルト3回）
Wait Between Tries：リトライ間隔（デフォルト1000ms）

外部APIへのリクエストやWebhookの受信など、ネットワーク起因の一時的なエラーに有効です。

設定の目安：Max Tries = 3、Wait = 5000ms（5秒）にしておけば、5秒おきに3回リトライして、それでもダメならエラーとして記録されます。

💡 実際にやってみた

Mac miniでn8nをDocker経由で常時稼働させていて、ある日ワークフローが止まっていることに気づきました。調べたら、呼び出していた外部APIが数秒間だけ不安定になっていただけでした。

Retry on Fail（Max Tries: 3、Wait: 5000ms）を設定したところ、それ以降は同様のネットワーク揺れでワークフローが止まることはなくなりました。

かかった時間：設定変更自体は5分以内

つまずいたポイント：「Settings」タブの場所が分からず最初は探した。ノードをクリック→右パネル→Settingsタブと進む

結果：外部API起因の一時停止がゼロに。長期間のヘッドレス運用でも安心感が段違いになった

【応用編】エラーワークフローでSlack通知を受け取る

ここからは中級者向けの内容です。

n8nには「エラーワークフロー」という仕組みがあります。ワークフローがエラーで止まったとき、別のワークフローを自動で起動できる機能です。

設定場所はワークフローの「Settings」（キャンバス右上の「…」メニューから開く）→「Error Workflow」です。

エラーワークフローの作り方（5ステップ）

新しいワークフローを作成する
「Error Trigger」ノードを追加する
その後に「Slack」や「Gmail」などの通知ノードをつなぐ
このワークフローを保存・有効化する
元のワークフローの Settings → Error Workflow に、このワークフローを指定する

Error Triggerノードには、エラーが起きたワークフロー名・ノード名・エラーメッセージなどの情報が入ってきます。これをSlackに投げると、「どのワークフローの、どのノードで、何のエラーが起きたか」を即座に把握できます。

Slackに送るメッセージの実装例

Slackノードのメッセージには、こんな内容を入れると実用的です：

⚠️ n8nワークフローエラー

ワークフロー: {{ $json.workflow.name }}
ノード: {{ $json.execution.lastNodeExecuted }}
エラー: {{ $json.execution.error.message }}
実行URL: {{ $json.execution.url }}

これで、エラーが起きた瞬間にSlackへ通知が飛んできます。対応が格段に速くなります。

n8nをどこで動かすか

n8nをクラウド上で常時稼働させたい場合、VPSが定番の選択肢です。XServer VPSやConoHa VPSなら、月額1,000円台からDockerが動くLinux環境を用意できます。Mac miniなど手元のマシンで動かしている場合は、そのままで問題ありません。エラーワークフローの設定方法は環境によらず同じです。