n8nが動かないときの原因切り分け｜エラー確認5ステップ

このページが合う人：n8nのワークフローが止まる、二重に動く、成功表示なのに結果が違い、どこから調べるか迷っている人。

分かること：失敗した場所、入力、HTTPステータスコードを順に確認し、安全に再実行できるか判断する方法。

先に用意するもの：失敗した実行履歴、最後に成功した実行履歴、同時刻の外部サービス側の処理結果。

次の行動：Executionsで失敗実行と最後の成功実行を開き、最初に違う箇所を1つ記録する。

最初に：メール送信、顧客登録、請求、在庫更新を含むワークフローは、同じ実行を繰り返す前に外部サービス側の処理結果を確認する。n8n上で失敗に見えても、直前の外部処理だけ成功している場合がある。

結論：実行履歴から失敗地点を1つに絞る

n8nのOverviewまたはProjectから実行履歴（Executions）を開き、対象ワークフローと失敗（Failed）で絞る。直近の失敗だけでなく、最後に成功した実行も開く。両者の入力件数、止まったノード、エラー文、実行時刻を比べる。

確認前にワークフローを広く編集しない。まず失敗実行を残し、エラー文を秘密値・個人情報を除いて記録する。その後、失敗ノードより前の入力を固定し、1つずつ変更する。

症状	最初に見る場所	主な原因候補
実行履歴がない	Trigger、Active状態、呼出URL、時刻	未公開、Test URL使用、時刻・timezone、送信元
赤いノードで停止	そのノードのInputとError	必須値、式、認証設定、API応答
成功だが結果が違う	各ノードの項目数と出力（Output）	分岐条件、配列、空値、参照元、固定データ
途中から不安定	失敗時刻、HTTPステータスコード、所要時間	429、5xx、timeout、入力増加、メモリ

ステップ1：Triggerが発火したか確認する

実行履歴（Executions）に対象時刻の記録がなければ、後続ノードではなく入口を調べる。WebhookはTest URLとProduction URLが別。Test URLはListen for test event中の開発用で、公開運用ではProduction URLを送信元へ登録し、ワークフローを公開する。

Webhook：送信元のURL、HTTP method、path、認証、送信履歴を確認する。
Schedule：ワークフローとn8n環境のタイムゾーン、予定時刻、公開状態を確認する。
アプリTrigger：認証設定、購読イベント、接続先サービス側の状態を確認する。

入口の切り分けでは、n8n画面だけを見ない。送信元サービスの履歴に送信があるか、HTTPステータスは何か、n8nに実行履歴が作られたかを時刻で照合する。

ステップ2：止まったノードのInputとErrorを読む

赤くなったノードを開き、エラー出力（Error output）と入力（Input）を分けて確認する。エラー文の全文、HTTPステータスコード、対象パラメータ、入力項目数を記録する。直前ノードが成功でも、必要な項目が空、型が違う、複数項目の一部だけ欠ける場合がある。

式を使う項目は、参照先ノード名、フィールド名、データ同士の対応を確認する。実行ごとに入力構造が変わるなら、正常時と失敗時のJSONを必要部分だけ比較する。認証情報、アクセストークン、Cookie、顧客データは記録へ貼らない。

ステップ3：HTTPステータスコードで認証とAPI障害を分ける

status・表示	確認順	避ける操作
400・422	リクエスト本文、型、必須項目、API仕様	同じpayloadの連続送信
401	認証設定、有効期限、アクセストークン、接続先	秘密値をチャットへ貼る
403	scope、role、resource権限、IP制限	権限を一括で最大化する
429	rate limit、Retry-After、実行頻度、並列数	待機なしの即時再試行
5xx・timeout	接続先障害、応答時間、payload量、再試行条件	副作用確認なしの全件再実行

HTTP Request nodeの公式トラブルシュートでは、APIのrate limitに対してRetry On FailかLoop Over ItemsとWaitを使う経路が案内されている。ただし再試行可能性はAPIごとに違う。作成・送信・請求系は、同一要求を識別するidempotency keyや外部側の既存結果を先に確認する。

ステップ4：成功表示と業務結果を分けて確認する

最後まで緑でも、期待件数、分岐、保存先、通知先が違えば業務上は失敗。各ノードの入力（Input）と出力（Output）で項目数と主要項目を追う。If、Switch、Merge、Loop、Codeノードの前後は特に件数を記録する。

開発中にピン留めしたデータは手動実行で使われ、本番実行では無視される。テスト時だけ成功し本番で値が変わる場合、ピン留めデータ、手動入力、Test URL、認証設定の差を確認する。

ステップ5：セルフホスト環境を確認する

複数ワークフローが同時に止まる、画面へ入れない、実行が途中で消える、再起動で一時復旧する場合、ワークフロー設定だけでなく実行基盤を調べる。

n8n、worker、task runner、databaseの起動状態とversion
CPU、メモリ、swap、disk空き容量、inode
データベース接続、移行、ロック、バックアップ成否
reverse proxy、TLS、DNS、Firewall、Webhook URL
直前のn8n update、community node、環境変数変更

ワークフロー1本だけ失敗するなら入力・設定・接続先を先に、複数ワークフローが同時に失敗するなら共通の認証設定、データベース、ネットワーク、n8n環境の資源を先に見る。メモリ不足の確認点はn8n VPSの必要メモリ実測、移行・更新後の不具合はn8n VPS移行の切戻し手順へ分けた。

再実行前の安全確認

ここまで確認しても場所を絞れない場合：ワークフロー名、失敗時刻、止まったノード、秘密値を除いたエラー文、期待した結果、実際の結果を用意する。

自分で続ける：下の安全確認を行い、合成データで1項目ずつ変更する。

文章で整理を依頼する：ワークフロー1本・症状1つだけを扱うn8nエラー原因切り分けの対象と料金を見る。初回連絡にファイル、秘密値、顧客情報は不要。

失敗した実行IDと実行時刻を記録する。
メール、顧客登録、決済、在庫など、外部側で成功済みの処理がないか確認する。
同じ入力を識別できる注文ID、message ID、idempotency keyがあるか確認する。
影響のないtest dataまたは1件へ絞る。
修正後は「現在のワークフロー」と「実行時のワークフロー」のどちらで再試行するか選ぶ。

n8nの失敗した実行は、以前の入力を使い、現在のワークフローまたは実行時のワークフローで再試行できる。便利な反面、外部サービスで完了した処理まで元に戻す機能ではない。どこまで成功したかを確認してから使う。

自力で解決しないとき、最初に揃える7項目

止まった操作とワークフロー名
期待した結果と実際の結果
秘密値・個人情報を除いたエラー文
失敗したノード名と実行時刻・timezone
最後に正常だった時期
n8n Cloudかセルフホストか、n8nのバージョン
直前に変えた設定、認証情報、API、入力形式

初回相談にパスワード、APIキー、認証情報のJSON、ワークフローファイル、画面キャプチャ、顧客・取引先データを添付しない。文章だけで切り分け可能かを先に判断する。

よくある質問

ワークフローは有効なのにWebhookが動かない

送信元へTest URLを登録していないか、Production URL・HTTPメソッド・パス・認証が一致するかを確認する。送信元の配信履歴とn8nの実行履歴を同じ時刻で照合する。

テスト実行では成功するのに本番で失敗する

Test URLとProduction URL、ピン留めデータ、手動入力、認証設定、タイムゾーンの差を確認する。ピン留めデータは本番実行で使われない。

Error Triggerを付ければ原因が直る？

直らない。Error Triggerは失敗時に別のエラー処理用ワークフローを実行し、通知や記録へつなぐ仕組み。元のワークフローの原因修正、重複防止、再実行判断は別に必要。

実行履歴が残っていない

ワークフローとn8n本体の実行履歴保存設定、削除・自動削除設定、ワークフロー削除の有無を確認する。ワークフローを削除すると、その実行履歴も削除される。

公式情報

広告・更新履歴

本ページにアフィリエイト広告なし。技術手順はn8n公式ドキュメントに照合し、個別環境の原因特定や解決を保証しない。

初稿・公式手順確認：2026-08-13 / 個別障害の実測なし / 次回更新：公開後の検索語と相談内容を匿名集計後