n8n 監視：何を見るべきか、n8n が教えてくれないことは何か
本番の n8n を監視するための実務的なガイドです。見るべき指標、標準機能でカバーできる範囲とできない範囲、今日から進められるチェックリスト、そして OutcomeGuard の考え方をまとめました。
n8n で監視すべきもの
実行の状態は、いちばん手軽に見られる一方で、分かることがいちばん少ない指標です。見落としたときの痛手が大きい順に並べると、次のとおりです。
そもそも実行されたか
スケジュールのあるワークフローは、最新の実行をトリガーが宣言した間隔と、そのトリガーのタイムゾーンで比べます。実行されなかったことは、エラーもログ行も残しません。
エラーで落ちたか
failed、crashed、canceled の実行。n8n がはっきり見せてくれる唯一の指標で、たいていは対策済みです。
仕事をしたか
実行ごとの件数。0 件の成功は、静かな障害でいちばん多い形です。
どこで終わったか
成功した実行の、最後に実行されたノード。これが手前に移ったときは、何もしない経路へアイテムが流れています。
どれくらいかかったか
そのワークフロー自身の普段と比べた所要時間。急に短くなれば入力が空、急に長くなれば連携先の応答が遅くなっている合図です。
設定は同じか
定義が変わったか、まだ有効か。「動かなくなった」の多くは、誰かの編集から始まります。
成果は実際に起きたか
データベースの行、ストレージのファイル、CRM のフィールド。関係者が本当に知りたいことに答えられる、唯一の指標です。
標準機能でできること、その限界
n8n には実際に使える道具があります。頼る前に、それぞれがどこまで見てくれるかを押さえておきましょう。
| 標準機能 | できること | どこで止まるか |
|---|---|---|
| 実行の一覧 | 直近の実行を状態、開始時刻、所要時間つきで並べ、開けばノードごとのデータも見られます。 | 毎日読む人はいません。起きなかった実行は表示されず、0 件の実行と中身のある実行は、開くまで見分けがつきません。 |
| Error Workflow | ワークフローが失敗したときに任意のワークフローを動かせます。例外の通知はこれで素直に組めます。 | 発火するのは例外が投げられたときだけです。トリガーが動かない、何も返さない、1 つ手前で終わる実行は、ここを呼びません。 |
| Stop and Error ノード | アイテムが通ってはいけない経路で意図的に失敗を出せます。静かな経路を本物のエラーに変える道具です。 | 静かな経路を自分で予測し、すべてのワークフローに自分で置き、ワークフローが変わるたびに置き続ける必要があります。 |
| Retry on fail と Continue On Fail | ノード内の一時的な問題を吸収します。不安定な API で実行全体を落とさずに済みます。 | Continue On Fail は、本当は失敗している実行を、エラーを抱えたままの成功に変えます。仕組みの上でサイレント障害を生む設定です。 |
| セルフホストのログとメトリクス | コンテナのログ、queue と worker のメトリクスから、n8n インスタンス自体の状態が分かります。 | 分かるのはプラットフォームの状態で、業務上の成果ではありません。インスタンスはまったく問題がないのに、その上のワークフローが 1 週間何も達成していない、ということもあります。 |
| 死活監視（dead man's switch） | 実行の最後に外部サービスへ ping を送り、ping が遅れたら通知を受けます。 | 証明できるのは ping のノードまで到達したことだけです。データが正しいか、足りているか、どこかに書き込まれたかは分かりません。 |
今日から進められるチェックリスト
新しい道具は要りません。必要なのは半日です。
- 有効なワークフローを全部並べ、1 本ごとに「動いている」とは何かを 1 文で書く。
- スケジュールのあるワークフローについて、想定する間隔と、トリガーが評価されるタイムゾーンを書き出す。
- 重要なワークフローすべてに Error Workflow を設定し、実際に人へ届くかを確認する。
- 出力が未接続の IF / Filter ノードを探し、Stop and Error ノードか通知につなぐ。
- データを取得するノードの直後に件数の判定を足し、0 件を目に見えるところへ流す。
- 重要なワークフローの普段の件数と所要時間を書き留め、ずれに気づける状態にする。
- Continue On Fail の設定を見直し、本物の失敗を隠しているものを外す。
- 日次の処理ごとに「いつまでに終わっていなければ困るのか」を決め、その時刻を過ぎたときに誰かが気づけるかを確かめる。
- 止まると最も高くつく 2〜3 本には、連携先が実際に変わったかを確認する処理を足す。
OutcomeGuard は同じ範囲をどう扱うか
上のチェックリストはワークフロー 5 本なら維持できます。50 本では維持できません。OutcomeGuard はそこを引き受けるためにあります。
- ワークフローごとに、そのワークフロー自身の実行から基準を学習します。実行間隔、所要時間、件数、成功時にいつも最後になるノード。
- cron と間隔指定 をタイムゾーン込みで解析するため、実行されるはずだった時刻の時点で、実行漏れを検出します。
- 失敗、サイレント障害、実行漏れ、出力ゼロ、件数と所要時間の異常、認証と連携先のエラー、設定の変更を検出します。
- Outcome Contract で期待する結果を宣言できます。実行された、成功した、N 件以上あった、時間内に終わった、連携先で確認できた。すべて満たしたときだけ正常です。
- 検出結果は重複を排除してインシデントにまとめ、クールダウンを挟むため、1 回の障害はメール 1 通になります。
- すべての検出結果に根拠、時刻、確信度、理由が付きます。履歴が足りないワークフローは、異常ではなくデータ不足として報告します。
よくある質問
- n8n に監視機能は付いていますか。
- 実行の一覧があり、ワークフローが失敗したときに Error Workflow を動かせます。セルフホストならログと queue のメトリクスも見られます。つまり、はっきり落ちた障害とプラットフォームの状態はカバーされています。一方で、予定された実行が行われなかったこと、成功した実行が 0 件だったこと、連携先が更新されなかったことは分かりません。
- n8n のワークフローが失敗したときに通知を受けるには。
- ワークフローの設定で Error Workflow を指定し、そこからメールやチャットへ送ります。あわせて、アイテムが通ってはいけない経路に Stop and Error ノードを置いてください。これがないと、静かな失敗は Error Workflow まで届きません。
- n8n が成功と表示するのに何も起きないのはなぜですか。
- 多いのは、未接続の IF / Filter の出力、0 件を返す取得元、空のレスポンスで返る期限切れの認証情報、そして Continue On Fail がエラーをデータに変えているケースです。n8n の定義ではこの実行は本当に成功しています。どのノードも例外を投げていないからです。
- スケジュールのワークフローが止まったことを、どう知ればよいですか。
- 最新の実行を、トリガーが宣言した間隔と、そのトリガーのタイムゾーンで比べます。間隔に少しの余裕を足した時間より開いていれば、実行されていません。原因として多いのは、非アクティブ化、タイムゾーンのずれ、意図と違う cron 式、インスタンスの再起動です。
- n8n の監視に書き込み権限は必要ですか。
- 不要です。ここで挙げたことは、すべて n8n の公開 REST API を読み取り専用のキーで読めば確認できます。OutcomeGuard はワークフロー、認証情報、設定に書き込みません。
- 実行の監視と成果の検証は何が違いますか。
- 実行の監視が答えるのは「動いたか、エラーが出たか」です。成果の検証が答えるのは「仕事が終わったか」です。期限までに実行され、成功し、件数が足りていて、時間内に終わり、連携先が実際に変わったか。前者では問題がないのに、後者では何週間も失敗し続けている、という状態は珍しくありません。
- n8n Cloud でもセルフホストでも使えますか。
- どちらでも使えます。OutcomeGuard は n8n の公開 REST API を使い、これは n8n Cloud もセルフホストも公開しています。セルフホストの n8n を OutcomeGuard から読むには、インターネットから接続できる必要があります。