n8n のワークフローが実行されないときの確認手順

最終更新: 2026年9月12日

ワークフローの Executions タブを開きます。空なら、本番では一度も実行されておらず、原因は設定です。ある日付でぷつりと終わる実行の列が見えるなら、そのワークフローは動いていて、その日付の前後で何かが変わりました。このページの後半へ進み、詳しくは「n8n の workflow が止まった」のページを読んでください。

1. 1ワークフローが有効になっていない。エディタからの手動実行は非アクティブでも通りますが、本番のトリガーは動きません。上部の Active スイッチを確認します。
2. 2Webhook をテスト URL で呼んでいる。Webhook ノードには、エディタで「Listen for test event」を押している間だけ受け付ける Test URL と、ワークフローが有効なときに受け付ける Production URL があります。呼び出し側にテスト URL を設定したままだと、エディタを離れた瞬間に届かなくなります。
3. 3cron 式が見た目と違う意味になっている。5 つのフィールドは 分・時・日・月・曜日 の順です。「0 9 * * 1」は毎週月曜 9 時で、平日毎日ではありません。cron が必要でなければ Schedule Trigger の間隔指定を使ってください。
4. 4タイムゾーンが日本時間ではない。インスタンスのタイムゾーン（GENERIC_TIMEZONE、初期値は UTC のことが多い）、ワークフロー自身のタイムゾーン設定、cron 式は別物です。ワークフローの 9 時が UTC の 9 時、つまり日本の 18 時になっているケースは非常に多いです。Asia/Tokyo を明示します。
5. 5n8n Cloud の実行数上限に達した。Cloud のプランには月間の実行数上限があり、超えるとワークフローが実行されなくなることがあります。Cloud のダッシュボードで使用量を確認します。
6. 6リバースプロキシの後ろで WEBHOOK_URL が違う。セルフホストの n8n は WEBHOOK_URL から Webhook の URL を組み立てます。内部アドレスや http のままを指していると、コピーした URL は外から届きません。
7. 7キューモードでワーカーがいない。キューモードではメインプロセスは予約だけをします。ワーカーが接続していない、あるいは Redis に繋がっていないと、実行は待ち行列に入ったまま何も動きません。
8. 8ポーリング型トリガーの credential が無効。Gmail、IMAP、Google Sheets、Airtable などのポーリング型トリガーは、期限切れや権限不足の credential で静かに止まります。実行の記録を一切残さないものもあります。

1. 1編集中に非アクティブになった。エディタからの保存、複製のインポート、テストのための切り替えで、非アクティブのまま残ることがあります。手動実行は通るので、健康に見えます。
2. 2複製がある。変更の検証のために誰かがコピーを作った。コピーが非アクティブで元を見ているか、その逆か。名前で検索して兄弟を探します。
3. 3インスタンスの再起動・移設。メモリ不足による強制終了、バージョン更新、ホストの移動のあと、ワークフローが非アクティブで戻ったり、メインプロセスだけがワーカー抜きで戻ったりします。
4. 4呼び出し元が止まった。Webhook 起動なら、こちら側には何も問題がありません。上流のシステムが URL を変えた、credential を失った、停止された、というだけです。
5. 5credential が失効した。ポーリング型トリガーが使う OAuth トークンや API キーは期限が切れます。トリガーは実行を生まなくなり、実行が始まらないので n8n にはエラーが出ません。
6. 6夏時間。現地時間 2:30 の cron は切り替えの夜に飛んだり二重に動いたりします。日本には夏時間がありませんが、インスタンスやワークフローのタイムゾーンが海外なら、年に 2 回、全実行が 1 時間ずれます。

後ろの 4 つは n8n のどこにもエラーを残しません。障害の正体が「実行が存在しないこと」だからです。だから、データを待っていた人が数日後に見つけます。監視するなら「いつ実行されるはずだったか」を知っている必要があり、何かが赤くなるのを待っていても見つかりません。

1. 1Active が入っているか確認し、次にワークフロー一覧を同じ名前で検索して兄弟を探す。
2. 2手動で 1 回動かす。通るなら本体は問題なく、調べる先はトリガー。
3. 3Webhook なら、ワークフローを有効にした状態で Production URL を curl で叩き、Executions タブを見る。
4. 4スケジュールなら、cron 式・ワークフローのタイムゾーン・インスタンスのタイムゾーンを書き出し、次の実行を日本時間で計算する。
5. 5最新の実行と間隔を比べる。間隔に少し余裕を足しても足りないほど空いているなら、実行されていない。最後の実行時刻の前後でインスタンスのログに再起動がないか見る。

• cron と interval のトリガーをタイムゾーン込みで解釈し、各実行がいつ予定されていたかを把握します。期限と猶予を過ぎても実行がなければ、予定時刻と実際の最終実行を根拠に「実行漏れ」を出します。
• スケジュールを宣言しないトリガー（Webhook、ポーリング）は、観測した実行のリズムを学習し、毎時動いていたワークフローが最長の間隔をはるかに超えて静かなら報告します。
• ワークフロー定義をハッシュで見ているので、非アクティブ化や編集はその時点で「設定ドリフト」として出ます。
• インスタンス自体に到達できないときは「不明」と言い、推測しません。
• API で読むだけです。ワークフローには何も足さないので、監視用ノードが非アクティブになる、という壊れ方が存在しません。

テスト実行では動くのに、自動では動かないのはなぜ？

テスト実行はエディタから非アクティブのワークフローを動かします。自動実行にはワークフローの有効化が要り、Webhook の場合はエディタを開いている間だけ受け付ける Test URL ではなく Production URL が要ります。

Schedule Trigger が発火しないのはなぜ？

多いのは、ワークフローが非アクティブ、cron 式が別の意味、タイムゾーンが UTC のまま、の 3 つです。次に、インスタンスの再起動で非アクティブに戻った、Cloud の実行数上限に達した、が続きます。

Webhook が 404 を返すのはなぜ？

ワークフローが非アクティブ（Production URL は有効中だけ登録される）、エディタ外で Test URL を使っている、リバースプロキシの後ろで WEBHOOK_URL が別ホストを指していて n8n が登録したパスとコピーした URL が食い違っている、のどれかです。

ワークフローが止まったら n8n は知らせてくれますか？

n8n 単体では知らせません。Error Workflow は実行がエラーを投げたときだけ動き、始まらなかった実行はエラーも実行も生みません。いつ実行されるはずだったかを知っているもの、つまりスケジュール点検のテンプレート、ハートビート、監視サービスが必要です。