のワークフローが本番で止まっていることに気づいたのは、翌朝クライアントから「通知が来てないんだけど」と連絡が来たときだった。
夜中に止まって、朝まで誰にも気づかれなかった。当たり前だ。僕はError Triggerを設定していなかった。
この記事でわかること：
- n8nのエラーが発生する典型パターン3つ
- 実際に踏んだエラーとそのとき何をやったか
- Error Triggerを設定していなかった失敗と、再発防止のための設定
n8nのワークフローが止まったとき、まず何を確認するか
まず落ち着いて、n8nの管理画面を開く。
左のメニューから「Executions」を選ぶと、過去の実行履歴が一覧で出てくる。緑色がSuccess、赤色がError。赤いのが並んでいたら、そこにヒントがある。
実行ログをどこで見るか
エラーになった実行をクリックすると、ノードごとの処理結果が見える。どのノードで止まったか、そのとき何のデータが来ていたか、エラーメッセージは何か。この3つを確認するのが最初の一歩だ。
エラーメッセージは英語で出ることが多い。最初は「何が書いてあるか全然わからない」と感じるかもしれない。わかる。僕もそうだった。ただ、メッセージをそのままコピーして検索すると大抵は答えが見つかる。n8nの基本的なエラーハンドリングについてはこまろぐの解説記事が参考になる。
エラーの種類をざっくり3分類する
本番で実際に出たエラーを振り返ると、だいたい3パターンに分類できる。
一時的なエラー（時間を置けば解決することが多い）
- 外部APIの一時的なダウン
- レート制限（APIを呼びすぎてブロックされる）
- タイムアウト（応答が遅くて制限時間切れ）
データ起因のエラー（設計を修正しないと繰り返す）
- 想定外のデータ形式（nullが来たり空文字が来たり）
- 必須フィールドの欠損
- 型の不一致（数値を期待しているのに文字列が来る）
認証・接続エラー（設定の問題）
- アクセストークンの期限切れ
- APIキーの無効化
- 接続情報の変更
この分類を頭に入れておくと、エラーメッセージを見たときにどの方向で対処するかが判断しやすくなる。
実際に踏んだエラーと、そのとき何をやったか
3ヶ月の本番運用で止まったのは4回。そのうち2回がAPIタイムアウト、1回がデータ型の不一致、1回が認証トークン切れだった。
APIのタイムアウト（もっとも多かった）
外部APIを呼び出すノードで、応答が30秒以上かかってタイムアウトになるケースが一番多かった。特に夜間バッチで複数のAPIを連続して呼び出すワークフローで発生しやすかった。
対処として、まずリトライ設定を入れた。HTTPリクエストノードの「On Error」設定を開いて、リトライ回数を3回、間隔を30秒に設定した。これだけで、同じエラーが翌週から出なくなった。
ただ、一時的なAPIダウンが重なると3回リトライしても失敗する。そういうケースは今でも手動確認が必要だ。
データ型の不一致でノードが止まる
Googleスプレッドシートからデータを取ってきて、次のノードで処理しようとしたとき「typeError: Cannot read properties of undefined」というエラーが出た。
原因は、スプレッドシートの特定の行が空だったこと。ワークフローは「データが必ずある」という前提で組んでいたが、本番データにはたまに空行が混じっていた。
対処は、データを受け取るノードの直後にIF分岐を追加して「空の場合はスキップ」というルートを作った。テストデータだけで確認していたときには気づかなかったパターンで、正直悔しかった。
認証トークン切れ
Gmail APIのアクセストークンが切れて、ノードが認証エラーを返した。n8nのCredentialsを確認したら有効期限が来ていた。
対処はCredentialsを再設定するだけで解決した。ただ、「いつ切れるか」が事前にわからないのが問題だ。今は定期的にCredentialの有効期限を確認するルーティンを月1で入れている。n8nのCredential管理の詳細はAI導入ラボの記事でも解説されている。
Error Triggerを設定していなかった話
これが一番の失敗だった。
n8nにはError Triggerという仕組みがある。ワークフローがエラーになったとき、別のワークフローを自動で起動してくれる機能だ。そのワークフローの中でSlackやメールに通知を飛ばすことができる。
僕はこれを「いつか設定しよう」と思いながら、最初の4ヶ月間設定しなかった。
結果として何が起きたかというと、ワークフローが止まっていても誰にも気づかれない状態になっていた。n8nの管理画面を開かない限りエラーに気づかない。フリーランスで一人でやっていると、毎日管理画面を開くわけではない。
設定方法は難しくない。まず「エラー通知用のワークフロー」を別途作る。このワークフローのトリガーにError Triggerノードを使う。その後に、Slackなり何なりで通知を送るノードを繋ぐ。これだけだ。
次に、エラー通知を受け取りたいワークフローの設定画面を開いて、「Error Workflow」にさっき作ったワークフローを指定する。これで、そのワークフローがエラーになるたびにSlackに通知が来るようになる。
設定してから2ヶ月で、2回通知が来た。どちらも夜中に止まったケースで、Error Triggerがなければ翌朝まで気づかなかったと思う。
止まってから気づいた設計の甘さ3つ
本番で止まった経験を通じて、「最初からやっておけばよかった」と感じた設計のポイントが3つある。
1. テストデータが綺麗すぎた
開発時に使ったテストデータは、自分で作った綺麗なデータだった。空行なし、型も統一、null値もなし。でも本番データは違う。過去のデータには空行も型のブレもある。テスト段階から本番に近いデータを使うべきだった。
2. エラーハンドリングを後回しにした
「動くことを先に確認して、エラー対処は後から」という考えで組んだ。動くことは確認できたが、エラー対処が後回しのまま本番に投入した。最低限のリトライ設定とError Triggerは、動作確認と同時に入れるべきだった。
3. 実行頻度の設計が甘かった
5分ごとに実行するワークフローを組んだが、処理の一部に「前回の結果に依存する処理」が混じっていて、エラーが連鎖するケースがあった。実行間隔と依存関係の整理は、組んだ時点で考慮すべきだった。
再発防止のために今やっていること
今は以下の3点をルールにしている。
ワークフローを本番に投入する前に必ずやること：
- Error Triggerの設定（どのワークフローにも必ず）
- 重要なAPIリクエストノードへのリトライ設定（3回・30秒間隔）
- 空値・null値が来たときの分岐追加
定期的にやること（月1）：
- 全ワークフローのCredential有効期限確認
- Executionsのエラー一覧を確認して異常なパターンがないかチェック
これをやるようになってから、「止まっていることに気づかない」という状況はなくなった。ただ、完全にエラーゼロというわけではない。止まっても通知が来て、すぐ対処できる状態になった、という話だ。
まとめ
n8nのワークフローが本番で止まる経験は、設定してすぐに始まるわけじゃない。最初の数日は問題なく動いて、安心した頃にエラーが出る。
一番やっておいてほしいのは、Error Triggerの設定だ。これだけでも「気づかないまま止まり続ける」という最悪のケースは防げる。
リトライ設定やデータ型のチェックは、その次の段階で整理していけばいい。最初から全部揃っている必要はない。ただ、Error Triggerだけは後回しにしない方が良い。僕みたいにクライアントから連絡が来てから気づく、という経験をしないために。
合わせて読みたい
– n8nの使い方入門：インストールから最初のワークフロー作成まで図解
– n8n AI Agentノードを自腹で試した：LLMと繋ぐだけで何ができて何ができないか正直に書く
コメント