n8n のワークフローが止まった：スケジュールが静かになる理由
ワークフローはあり、最後の実行は成功、そこから先が何もない。エラーは存在しません。エラーを出す実行そのものが起きていないからです。気づきにくい障害ですが、見る場所さえ分かれば原因は突き止められます。
n8n ではこう見えます
実行の一覧が、ある日付でぷつりと終わっています。最新の実行は緑。ワークフローを開いても、完成して問題なく見えます。そのワークフローがデータを送っていた先も、その日から更新が止まっています。
- 最後の実行が、スケジュールの間隔より何時間も、何日も古い。
- ワークフローの Active がオフになっている。オンなのに最近の実行がない場合もある。
- 同じワークフローの複製があり、有効なのは片方だけ。
- 実行はされているが 1 時間ずれている。または想定した曜日に動いていない。
よくある原因
スケジュールが発火しないときの理由は、そう多くありません。
ワークフローが非アクティブになった
編集中の保存、複製のインポート、検証のための切り替えで非アクティブのまま残ることがあります。手動実行は通るので正常に見えます。
スケジュールトリガーのタイムゾーンのずれ
インスタンスのタイムゾーン、ワークフローのタイムゾーン、cron 式の 3 つが食い違っている。08:30 が別の地域の 08:30 になっていたり、夏時間の切り替わりで 1 日飛んだりします。
cron 式が意図と違う
フィールドの位置がひとつずれている。あるいは曜日と日付の組み合わせが、ほとんど同時に成立しない条件になっている。
インスタンスの再起動や移設
コンテナの再起動、移設、メモリ不足による強制終了のあと、ワークフローが非アクティブで戻ることがあります。queue モードの worker が実行を拾わない状態で戻ることもあります。
webhook の呼び出し側が止まった
webhook トリガーの場合、n8n 側には何も問題がないことがあります。呼び出す側のシステムが URL を変えた、認証情報を失った、あるいは停止した、というだけのケースです。
ポーリングトリガーの認証情報の失効
認証情報が失効したポーリングトリガーは、実行の一覧にエラーを残さないまま止まることがあります。
いまの n8n で確認する方法
5 分の確認で、ほとんどの場合は切り分けられます。
Active を確認し、次に複製を探す
ワークフローが有効かを確認します。そして、有効であるべき側を見ているかも確認します。ワークフロー名で検索して、よく似た複製がないか見てください。
トリガーノードとインスタンスのタイムゾーンを突き合わせる
cron 式とワークフロー側のタイムゾーン設定を、インスタンスのタイムゾーンと並べて見ます。そのうえで、次の実行が日本時間で何時になるかを計算します。
最後の実行と間隔を比べる
1 時間ごとのスケジュールで最新の実行が昨日なら、答えは出ています。失敗したのではなく、実行されていません。
手動で 1 回動かす
手動実行が通るなら、処理の中身は問題ないと分かります。調べる先はワークフローの本体ではなくトリガーです。
インスタンス自体を確認する
実行が止まった日付の前後で、n8n のログやコンテナの状態を見ます。その時刻に再起動があれば、それで説明がつきます。
OutcomeGuard はどう検出するか
実行されなかったことは、記録が何も残らない障害です。見つけるには、いつ実行されるはずだったかを知っている仕組みが要ります。
- cron と間隔指定 のトリガーをタイムゾーン込みで解析し、次の実行がいつだったかを把握します。
- 期限と猶予時間を過ぎても実行がなければ、想定時刻と実際の最終実行を根拠として MISSED_RUN を出します。
- スケジュールが宣言されていないトリガーは、観測した実行間隔を学習し、一定だったリズムが途切れた時点で気づきます。
- ワークフロー定義をハッシュで見ているため、非アクティブ化や編集は CONFIG_DRIFT としてその時点で出ます。
- インスタンス自体に到達できない場合は、ワークフローについて推測せず UNKNOWN にします。