n8n のサイレント障害：成功と出ているのに、何も起きていない
サイレント障害とは、エラーを出さずに終わり、しかも仕事をしていない execution です。n8n 側に報告すべきことがないため通知も飛ばず、たいていは数日後、データを待っていた人が気づきます。
n8n ではこう見えます
execution の一覧は緑が並んでいます。所要時間も不自然ではありません。開いてみても、きれいに終わっています。それでもシートに新しい行はなく、CRM にリードは入らず、Slack のチャンネルは火曜から静かなままです。
- 成功した実行が、以前より手前の node で終わるようになっている。
- 所要時間が急に短くなった。30 秒かかっていた処理が 400 ミリ秒で終わる。
- ある日を境に、webhook や polling の trigger の execution が 1 件もない。理由を示すエラーもない。
- 以前は数十件動いていた workflow の件数が 0 件になっている。
よくある原因
サイレント障害のほとんどは、例外を投げる node ではなく、静かに行き止まりになる経路から生まれます。
接続されていない IF / Filter の出力
false 側に node がつながっていない。条件が反転した瞬間から、すべての item が未接続の出力へ抜け、それでも execution は成功になります。
取得元が 0 件を返している
空の API レスポンスや、条件に合致しないクエリはエラーではありません。後続の node は何も受け取らず、何もせず、成功します。
編集中に trigger が止まった
検証のために複製して、元のほうを非アクティブのまま残した。あるいは非アクティブの状態で保存した。手動実行は通るので、見た目は健康です。
webhook の URL が変わった
webhook node を作り直すとパスが変わります。呼び出し側は古い URL に投げ続け、誰もそれに気づきません。
credential の期限切れ
401 を例外にせず、空の結果として返す node があります。execution は中身のないまま成功します。
Continue On Fail が有効なまま
失敗時に継続する設定の node は、エラーをデータとして次へ渡します。仕事は行われていないのに execution は成功で終わります。
いまの n8n で確認する方法
見る習慣さえあれば、サイレント障害のかなりの部分は n8n だけでも拾えます。
最後に実行された node を比べる
最近の成功した実行をいくつか開き、どこで終わっているかを見比べます。いつもより手前で終わっていれば、静かに壊れている可能性が高いところです。
所要時間を比べる
execution の一覧で、ここ数週間の実行時間を見ます。ある時点から短くなってそのままなら、item を運ばなくなった経路があります。
件数を見る IF を置く
データを取得する node の直後に件数を判定する IF を置き、0 件の経路を通知する node につなぎます。
Stop and Error node を置く
通ってはいけない経路（false 側、空の結果、想定外のステータス）に Stop and Error node を置きます。n8n が成功ではなく失敗として記録するようになります。
Error Workflow を設定する
workflow の設定で Error Workflow を人に届く処理に向けます。発火するのは例外が投げられたときだけなので、手順 4 を先に済ませてください。
OutcomeGuard はどう検出するか
OutcomeGuard は「成功」を答えとして扱いません。その workflow 自身の履歴に照らして確かめるべき主張として扱います。
- 成功した実行がいつもどの node で終わるかを学習し、手前で終わるようになったら SILENT_FAILURE を出します。
- trigger ごとの普段の間隔を学習し、エラーを残さず静かになった場合に検出します。
- 0 件がその workflow にとって普通かどうかを学習し、普通でない場合だけ EMPTY_OUTPUT を出します。
- 所要時間と件数をその workflow 自身の基準と比べるため、どちらかが恒久的に落ち込めば見えます。
- 履歴が足りない workflow は推測せず、足りないと書きます。
静かに止まっているものを探す
無料ヘルスチェックは、instance 上のすべての workflow についてこのパターンを探します。読み取り専用、1 分ほど、API key は終了後に破棄します。