本文へ移動

n8n の監視ツール比較:5 つの方法で「何が見つかるか」は違う

n8n を監視する方法は、手元にある実行一覧から専用サービスまで 5 つあります。見つけられる障害の種類はそれぞれ違います。ここでは障害の種類を軸に比べ、自分のワークフローが実際に壊れる形を最小の構成で押さえる選び方をまとめます。

結論から

n8n 標準の Error Workflow が拾うのは「エラーを投げた実行」だけです。無料のコミュニティテンプレートを使えば、スケジュール実行が止まったことを 1 日以内に検知できます。ハートビート型のサービスは「実行が最後まで到達した」ことしか保証しません。Prometheus や Grafana、SigNoz、Dynatrace などの基盤監視はインスタンスの健康を見ますが、仕事が終わったかは見ません。「成功と出ているのに仕事が終わっていない」を見つけられるのは、実行履歴を読み、ワークフローごとの平常時と比べる監視だけです。OutcomeGuard はその一つで、読み取り専用、ワークフローにノードを足しません。

最終更新: 2026年9月12日

n8n の障害は 6 種類。それぞれ「何を見ていれば気づけるか」が違う

機能一覧で比べると、いちばん大事な問いが隠れます。どの障害に、いつ気づけるのか。n8n のコミュニティフォーラムと、OutcomeGuard の無料診断で繰り返し出てくる 6 つの型です。

障害n8n 上の見え方気づくために見る必要があるもの
エラー停止赤い実行とエラーメッセージ実行のステータス。n8n が自分で報告してくれる唯一の型
実行漏れ何も出ない。実行そのものが存在しないスケジュール。次の実行がトリガーのタイムゾーンで何時のはずだったか、実際に起きたか
サイレント障害(途中終了)緑の実行が、以前より手前のノードで終わっている成功した実行が普段どのノードで終わるか。履歴との比較
出力ゼロ緑の実行で items が 0件数。そのワークフローで 0 件がどれくらい普通か
出力の固定化緑の実行が、同じ結果を出し続ける書き込み先が実際に変わっているか(行数、ファイル日付、更新日時)
成果の未達緑の実行。しかし業務上の結果は起きていない結果に関する条件。N 件以上、X 秒以内、期限までにノード Y に到達

方法 1:n8n 標準機能

実行一覧、Error Workflow(Error Trigger ノード)、Stop and Error ノード、Retry On Fail、Continue On Fail。無料で、すでに入っていて、何よりも先に設定する価値があります。

  • 見つかるもの:エラー停止。Error Workflow 経由で即時。
  • 見つからないもの:エラーを投げない失敗すべて。トリガーが発火しない、0 件を返す、1 ノード手前で終わる。どれも Error Workflow を呼びません。
  • 手間:本来 items が流れないはずの分岐に Stop and Error を置けば、静かな経路を本物のエラーに変えられます。ただし、静かな経路を先に予測し、全ワークフローに置き、変更のたびに保ち続ける必要があります。
  • Continue On Fail は、本物の失敗を「エラーをデータとして運ぶ緑の実行」に変えます。作りとしてサイレント障害になるので、意図して使うか、使わないかのどちらかです。

方法 2:スケジュールを点検する無料テンプレート

n8n のテンプレート「Monitor scheduled workflow health in n8n with automatic trigger checks」(コミュニティテンプレート 13290、2026-09-12 確認)は、自分の n8n の中で 1 日 1 回動くワークフローです。n8n API で有効なワークフローを列挙し、Schedule Trigger の cron 式を解釈し、最後の実行と許容ギャップ(日次 48 時間、週次 8 日、月次 35 日)を比べ、期限切れのワークフローを列挙してエラーを投げます。あとは Error Workflow で通知できます。

  • 見つかるもの:スケジュール実行・ポーリング実行の停止。1 日以内。
  • 見つからないもの:サイレント障害、出力ゼロ、出力の固定化、成果。スケジュールを持たない Webhook 起動のワークフロー。そして自分自身。監視ワークフローが止まったら、誰も報告しません。
  • 向いている場面:セルフホストの 1 インスタンスに日次ジョブが数本あり、検知が 1 日遅れても許容できる場合。

有料の監視サービスが必ず超えなければならない、正直な基準線です。困っているのが「夜間ジョブが止まっていて 1 週間気づかなかった」だけなら、まずこのテンプレートを入れて足りるか試してください。

方法 3:ハートビート型・cron 監視サービス

汎用のデッドマンスイッチ(Healthchecks や Cronitor のような型)。ワークフローの最後に HTTP Request ノードで URL を叩き、叩かれなかったらサービスが通知します。

  • 見つかるもの:実行漏れと、最後のノードに届く前に死んだ実行。数分以内。
  • 見つからないもの:データに関することすべて。0 件を取得し、何も書かず、ハートビートだけ叩いた実行は完璧に見えます。
  • 手間:ワークフローごとに 1 ノード。しかもそのノード自体が、消される・切断される・通らない分岐に置かれるという壊れ方をします。

自分のインスタンスなら何が報告されるか見る

無料ヘルスチェックは n8n のインスタンス 1 台を API で読み、各ワークフローを自身の履歴と比べて、実行漏れ、サイレント障害、中身のない成功を一覧にします。読み取り専用で、API キーはスキャン後に破棄します。

無料ヘルスチェックを実行読み取り専用。カード登録は不要です。

方法 4:基盤監視(Prometheus・Grafana・OpenTelemetry)

セルフホストの n8n は Prometheus 形式のメトリクスを出せます。SigNoz や Dynatrace などの OpenTelemetry 連携もあります。キュー長、ワーカー数、メモリ、実行数の Grafana ダッシュボードは、n8n インスタンス自体を運用する標準です。

  • 見つかるもの:インスタンスのダウン、ワーカーの詰まり、メモリ逼迫、実行総数の急減。
  • 見つからないもの:個々のワークフローが仕事を終えたか。完全に健康なインスタンスの上で、1 週間何も達成していないワークフローが動いていても、ダッシュボードは緑のままです。
  • 向いている場面:すでに Prometheus や監視基盤を運用しているチーム。ワークフロー単位の監視の代わりではなく、補完です。

方法 5:n8n 専用の監視サービス

2025〜2026 年に小さなカテゴリが生まれました。n8n だけのために作られ、実行履歴を読んでワークフローごとの振る舞いと比べるサービスです。2026-09-12 時点で公開サイトから確認できたものに Watchflow、Midwatch、OutcomeGuard があり、ほかにも小規模なツールがいくつかあります。価格は変わるためここには書きません。各社が公開しています。

Watchflow
実行漏れ・サイレント障害・出力の固定化を掲げ、n8n 公式テンプレートを公開しています。設定では監視対象のワークフローにステップを 1 つ足します。ハートビートと同じ取引で、監視役が監視対象の中にいる形です。
Midwatch
n8n(と Cloudflare Workers)の読み取り専用監視。検知としてサイレント障害、設定ドリフト、ゾンビ実行、周期、エラー停止、到達性を挙げています。通知はメール・Slack・Telegram、14 日間の試用。
OutcomeGuard(当サイト)
API キーによる n8n の読み取り専用監視。ワークフローにノードは足しません。ワークフローごとに平常時を学習し(直近の実行は学習から外し、障害が自分の基準を汚さないようにします)、解釈したスケジュールから実行漏れを、終端ノードからサイレント障害を、そのワークフローの 0 件率から出力ゼロを、さらに出力の固定化・件数と所要時間の異常を検出します。結果の条件を Outcome Contract として書けます。通知はメール。3 ワークフローまで無料、Solo 月 19 ドル、Pro 月 39 ドル、Agency 月 99 ドル。2026 年 9 月に公開したばかりで、お見せできる利用者レビューはまだありません。

3 社を分けるのは検知の一覧ではありません。それは似てきます。違いは監視役の置き場所です。ワークフローの中(足したノード)か、外(読むだけの API キー)か。中に置けば「ここまで到達した」の確認は速い反面、静かに壊れる部品が 1 つ増えます。外に置けばワークフローに保守すべきものが増えず、実行を履歴と出力で判定できます。

どれを選ぶか

1 インスタンス、日次ジョブが数本、予算なし
Error Workflow を設定し、静かな分岐に Stop and Error を置き、無料テンプレートを入れる。実行漏れの検知が 1 日遅れることは受け入れる。
Webhook・イベント起動のワークフローが中心
テンプレートは役に立ちません(スケジュールがない)。普段の周期を学習して静かになったら知らせるもの、つまりハートビートか、実行履歴を読むサービスが必要です。
「成功」に一度でも痛い目を見た
0 行しか書かれていなかった、フィルタが当たらなくなっていた、分岐に items が流れなくなっていた。これは履歴ベースの検知(終端ノード、件数、所要時間)でしか見えません。下の無料診断を自分のインスタンスに掛けて、すでにその状態のものがないか見てください。
顧客のインスタンスを複数運用する制作会社
顧客ごとの workspace と、そのまま転送できるレポートを基準に選ぶ。OutcomeGuard の Agency プランと Midwatch の Agency プランがここを狙っています。
すでに Prometheus と Grafana がある
インスタンスにはそのまま使う。成果の監視をワークフロー単位で足す。答える問いが違います。

OutcomeGuard が合わない場合

  • インスタンスのメトリクス(CPU、メモリ、キュー長)が必要。OutcomeGuard は収集しません。Prometheus か監視基盤を使ってください。
  • 外部サービスを使わず、すべて n8n の中で済ませたい。無料テンプレートと Stop and Error が正解です。
  • 今すぐ Slack や Telegram への通知が必要。OutcomeGuard の通知はメールです。他のチャネルはロードマップで、まだ出ていません。
  • ワークフローが手動実行だけ。学習する周期がなく、検証するものもほとんどありません。

よくある質問

n8n に監視機能は付いていますか?
実行一覧、実行がエラーを投げたときに動く Error Workflow、セルフホスト向けのメトリクスがあります。スケジュール実行が止まったこと、エラーなしで途中終了した実行、0 件しか出さなかった実行は検知しません。
無料の監視テンプレートで足りますか?
1 インスタンスのスケジュール実行なら足りることが多いです。テンプレート 13290 は 1 日 1 回スケジュールを点検し、Error Workflow 経由で通知します。Webhook 起動、サイレント障害、出力ゼロは見えず、自分自身の停止も報告できません。
実行監視と成果監視の違いは何ですか?
実行監視は「ワークフローが動いたか、エラーを投げたか」を問います。成果監視は「意図した結果が起きたか」を問います。行が書かれたか、メールが送られたか、ファイルが変わったか。前者に合格し後者に落ちる実行は、エラーなしに起きます。
監視サービスはワークフローを編集しますか?
方式次第です。ノードを足す方式は各ワークフローの編集が必要です。OutcomeGuard のような読み取り専用の方式は、ワークフローと実行を読める n8n API キーだけを使い、何も変更しません。
実行漏れはどれくらいで検知されますか?
無料テンプレートは 1 日 1 回です。OutcomeGuard は Free プランで 5 分ごと、Solo で 2 分ごと、Pro と Agency で毎分ポーリングし、スケジュールの期限と猶予を過ぎた時点で実行漏れを出します。

自分のインスタンスなら何が報告されるか見る

無料ヘルスチェックは n8n のインスタンス 1 台を API で読み、各ワークフローを自身の履歴と比べて、実行漏れ、サイレント障害、中身のない成功を一覧にします。読み取り専用で、API キーはスキャン後に破棄します。