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