本文へ移動
OutcomeGuard
メニュー

n8n のサイレント障害：成功と出ているのに、何も起きていない

サイレント障害とは、エラーを出さずに終わり、しかも仕事をしていない実行です。n8n 側に報告すべきことがないため通知も飛ばず、たいていは数日後、データを待っていた人が気づきます。

n8n のサイレント障害とは

サイレント障害とは、n8n が成功として記録した実行なのに、その実行が本来やるべき仕事が起きていない状態です。どのノードもエラーを投げていないので Error Workflow は動かず、何も赤くなりません。障害は結果にだけ現れます。増えていない行、届いていないメール、変わっていないファイル。そして気づくのはたいてい、それを待っていた人です。

サイレント障害の 6 つの型

「サイレント障害」という言葉は、いくつかの違う状況に使われています。原因も、見つけ方も違うので、名前を分けておくと話が早くなります。右端の列は、OutcomeGuard がそれぞれに出す判定です。

型n8n 上の見え方典型的な原因OutcomeGuard の判定
実行漏れある日付以降、実行がまったくない非アクティブ化、タイムゾーンや cron の誤り、インスタンス再起動、呼び出し元の停止実行漏れ
途中終了緑の実行が、以前より手前のノードで終わる何も接続されていない IF や Filter の分岐、当たらなくなった Switch の条件サイレント障害
中身のない成功以前は数十件だった実行が 0 件の緑空の API 応答、何にも当たらないクエリ、エラーではなく空を返す認証情報出力ゼロ
出力の固定化緑の実行が同じ結果を出し続ける上流データの凍結、キャッシュされた応答、古い日付に固定されたフィルタ出力の固定化
件数の急減0 ではないが、普段よりはるかに少ない件数の緑2 ページ目以降のページングが壊れた、上流の部分障害、200 で短いリストを返すレート制限件数の異常
成果の未達緑の実行。しかし業務上の結果が起きていない実行は終わったが書き込みノードに到達していない、あるいは必要な件数に届いていない成果の未達（Outcome Contract）

n8n ではこう見えます

実行の一覧は緑が並んでいます。所要時間も不自然ではありません。開いてみても、きれいに終わっています。それでもシートに新しい行はなく、CRM にリードは入らず、Slack のチャンネルは火曜から静かなままです。

  • 成功した実行が、以前より手前のノードで終わるようになっている。
  • 所要時間が急に短くなった。30 秒かかっていた処理が 400 ミリ秒で終わる。
  • ある日を境に、webhook やポーリングのトリガーの実行が 1 件もない。理由を示すエラーもない。
  • 以前は数十件動いていたワークフローの件数が 0 件になっている。

よくある原因

サイレント障害のほとんどは、例外を投げるノードではなく、静かに行き止まりになる経路から生まれます。

  • 接続されていない IF / Filter の出力

    false 側にノードがつながっていない。条件が反転した瞬間から、すべてのアイテムが未接続の出力へ抜け、それでも実行は成功になります。

  • 取得元が 0 件を返している

    空の API レスポンスや、条件に合致しないクエリはエラーではありません。後続のノードは何も受け取らず、何もせず、成功します。

  • 編集中にトリガーが止まった

    検証のために複製して、元のほうを非アクティブのまま残した。あるいは非アクティブの状態で保存した。手動実行は通るので、見た目は正常です。

  • webhook の URL が変わった

    webhook ノードを作り直すとパスが変わります。呼び出し側は古い URL へ送り続け、誰もそれに気づきません。

  • 認証情報の期限切れ

    401 を例外にせず、空の結果として返すノードがあります。実行は中身のないまま成功します。

  • Continue On Fail が有効なまま

    失敗時に継続する設定のノードは、エラーをデータとして次へ渡します。仕事は行われていないのに実行は成功で終わります。

いまの n8n で確認する方法

見る習慣さえあれば、サイレント障害のかなりの部分は n8n だけでも拾えます。

  1. 最後に実行されたノードを比べる

    最近の成功した実行をいくつか開き、どこで終わっているかを見比べます。いつもより手前で終わっていれば、そこで静かに壊れている可能性が高いです。

  2. 所要時間を比べる

    実行の一覧で、ここ数週間の実行時間を見ます。ある時点から短くなったまま戻らないなら、アイテムが流れなくなった経路があります。

  3. 件数を見る IF を置く

    データを取得するノードの直後に件数を判定する IF を置き、0 件の経路を通知するノードにつなぎます。

  4. Stop and Error ノードを置く

    通ってはいけない経路（false 側、空の結果、想定外のステータス）に Stop and Error ノードを置きます。n8n が成功ではなく失敗として記録するようになります。

  5. Error Workflow を設定する

    ワークフローの設定で、Error Workflow に人へ通知するワークフローを指定します。発火するのは例外が投げられたときだけなので、手順 4 を先に済ませてください。

OutcomeGuard はどう検出するか

OutcomeGuard は「成功」の表示をそのまま信じません。そのワークフロー自身の履歴に照らして、本当に仕事が終わったかを確かめます。

  • 成功した実行がいつもどのノードで終わるかを学習し、手前で終わるようになったら SILENT_FAILURE を出します。
  • トリガーごとの普段の間隔を学習し、エラーを残さず静かになった場合に検出します。
  • 0 件がそのワークフローにとって普通かどうかを学習し、普通でない場合だけ EMPTY_OUTPUT を出します。
  • 所要時間と件数をそのワークフロー自身の基準と比べるため、どちらかが下がったまま戻らなければ気づけます。
  • 履歴が足りないワークフローは推測で判定せず、履歴が足りないと報告します。

静かに止まっているものを探す

無料スキャンは、インスタンス上のすべてのワークフローからこのパターンを探します。読み取り専用で、1 分ほどで終わります。API キーは終了後に破棄します。

無料スキャンを実行仕組みを見る

よくある質問

何もしていないのに n8n が成功と表示するのはなぜ？
n8n が報告するのは実行であって、結果ではありません。どのノードもエラーを投げなければ、すべてのアイテムが接続のない分岐へ抜けても、元データが 0 件でも、その実行は成功です。
Error Workflow でサイレント障害は拾えますか？
拾えません。Error Workflow は実行がエラーを投げたときだけ動きます。静かな経路を見えるようにするには、その経路に Stop and Error ノードを置き、n8n に失敗として記録させます。
n8n のサイレント障害はどう検知しますか？
直近の成功した実行を、そのワークフロー自身の履歴と比べます。終わるノード、件数、所要時間、周期。手前で終わる、何も運んでいない、所要時間が 10 分の 1、あるいは実行が来なくなった。それが合図です。OutcomeGuard はこの比較を API 経由で自動で行います。
サイレント障害と実行漏れは何が違いますか？
実行漏れは、実行されるべきときに実行が存在しないこと。サイレント障害は、実行が起き、成功し、何も達成しなかったこと。どちらも n8n に報告すべきエラーがないので静かですが、見つけ方は違います。
Continue On Fail はサイレント障害の原因になりますか？
なります。失敗時に続行する設定のノードはエラーをデータとして次へ渡し、仕事が起きていないのに実行は成功で終わります。エラー側の経路を明示的に処理する場所だけで使ってください。