n8nの定期実行は、Schedule Triggerの時刻、workflowのタイムゾーン、自動実行できる公開状態をセットで確認します。手動実行が成功していても、毎朝の起動が正しく設定できたとは限りません。
日本時間の9時を、どのタイムゾーンで解釈するか
workflowの設定でタイムゾーンを確認し、日本時間で動かすならAsia/Tokyoを選びます。Schedule Triggerはworkflowの設定を使い、それがなければインスタンス側のタイムゾーンを使うため、担当者のPCの時計だけでは判断できません。
毎日の実行なら日単位の間隔を選び、時間を9、分を0として設定する方法があります。Cron式で細かく指定する場合も、式とタイムゾーンは一緒に記録します。細かな設定はSchedule Triggerの公式説明を確認してください。
公開前に短い間隔で動くことを確かめる
本番のメール送信を外した試験用workflowで、時刻と実行IDだけを記録する構成にします。短い間隔で自動起動することを確認してから本番の時刻へ戻し、その版を公開します。保存した編集と公開中の版が同じかも確認が必要です。
確認する記録
workflowの名前と版:
タイムゾーン:Asia/Tokyo
設定した時刻:09:00
自動起動した時刻:
実行ID:
最後の処理まで完了したか:
記録した「起動」と「完了」を分けると、9時に始まったが外部API待ちで止まった状況を見つけられます。
動かないときは、起動記録から順に調べる
| 見えている状態 | 先に確認すること |
|---|---|
| 実行が一つもない | 公開状態、トリガー設定、workflow/インスタンスの時刻設定 |
| 実行はあるが失敗 | 最初に失敗したノード、認証、入力、外部上限 |
| 起動時刻だけずれる | 表示時刻と設定時刻のタイムゾーン |
| 前の実行が終わっていない | 処理時間、同時起動の扱い、重複する対象 |
トリガーの設定を変更した後は、変更が公開中の版に反映されているかを確かめます。画面上の編集だけ見て、翌朝まで待つと切り分けが一日遅れます。
止まっていた期間を、無条件にまとめて再実行しない
停止していた分を取り戻す場合は、どの期間を取得し、何を処理済みとみなすかを決めます。日時の境界を固定し、処理済みIDを照合してから再開します。未実行の定期枠がすべて自動で補われるとは考えないでください。
通知の失敗とデータ更新の失敗も分けて扱います。再試行の条件はn8nのエラー処理へ整理し、まず「自動起動した記録があるか」を最初の確認にしてください。