n8nで処理が失敗したら、すべてを再試行する前に、どこまで成功したかを確認します。一時的な接続失敗、認証の問題、入力の不備、結果が分からないタイムアウトでは、次に行う操作が違います。
再試行できるかは、エラー名と処理の性質で決める
| 観測した状態 | 次に取る対応 |
|---|---|
| 一時的な制限や接続障害 | 待ち時間と回数の上限を決めて再試行する。更新操作なら重複防止も確認する |
| 認証切れ・権限不足 | 停止し、接続と権限を直す。待つだけでは解決しない |
| 必須項目の欠落 | 入力を確認待ちへ戻す。同じ入力を繰り返さない |
| 送信後にタイムアウト | 相手側の結果を確認する。未実行と決めつけて再送しない |
読むだけの処理をやり直す場合と、請求、投稿、メール送信をやり直す場合では、失敗の影響が違います。HTTPの状態コードだけで一律に再試行を選ばず、外部に結果を残す操作かを見ます。
通知・再試行・停止は、それぞれ役割が違う
| 次の処理 | 進める条件 | 残す情報 |
|---|---|---|
| 通知 | 担当が原因と結果を調べる必要がある | 実行ID、失敗した操作、確認先 |
| 再試行 | 一時障害で、再送しても結果を照合できる | 依頼ID、回数、間隔、保存先の状態 |
| 停止・確認待ち | 権限や入力が不正、保存したか分からない | 止めた理由、再開するための条件 |
通知が届くことは、業務処理が完了した証拠ではありません。エラーを通知してから何を確認するかまで決めます。書き込み済みか不明な処理は、自動再送の回数を増やす前に重複防止の条件を照合してください。
Error Triggerで、調べるための情報を集める
n8nの公式エラー処理の説明では、Error Triggerから始まるworkflowを作り、対象workflowの設定でError workflowに指定します。失敗時にworkflow名や失敗箇所などを通知する構成にできます。
通知は機密の入力全文ではなく、調査へ戻れる情報を中心にします。実行データが保存されていない場合やTriggerの段階で失敗した場合には、実行IDや実行URLが得られないことがあるため、それらを必須と決めつけません。
失敗日時：
workflow名：
最後に確認できた処理：
入力の識別ID：
保存済みの外部結果ID：
失敗内容：
自動再試行した回数：
次に確認する担当者：保存済みの結果から、再開する場所を決める
「記事を登録する → 登録結果を通知する」という二段階で、通知だけが失敗したとします。記事のIDが残っていれば、記事をもう一度作らず、通知だけをやり直せます。
逆に、登録結果が保存される前に接続が切れると、作成済みか判断できません。登録先を原稿IDなどで照合し、状態を確認してから再開します。再試行回数を増やすだけでは、この不確実さは解消しません。
エラー処理自体が働くかを、検証環境で試す
- テスト用の入力と出力先を用意し、正常に一件通す。
- 入力不足を作り、意図した確認待ちへ入ることを確かめる。
- 失敗させる箇所を一つ決め、後続が勝手に進まないか確認する。
- 実際に使う起動方法でエラー通知を確かめる。手動テストと通常運用を同じ結果とみなさない。
- 途中まで成功した状態から再開し、出力が重複しないことを見る。
確認票には「予想した結果」と「観測した結果」を分けて記入します。通知先が止まった場合も確認できるよう、実行履歴を定期的に見る担当を決めておきましょう。WordPress登録を扱うなら下書きの重複防止と再試行が具体例になります。