AI活用

n8nの定期実行を設定する|タイムゾーンと動かないときの確認順

n8nのSchedule Triggerで日本時間の定期実行を設定する考え方を解説。公開状態、起動と完了の記録、時刻ずれ、停止期間の再実行を順番に確認します。

この記事の目次
  1. 日本時間の9時を、どのタイムゾーンで解釈するか
  2. 公開前に短い間隔で動くことを確かめる
  3. 動かないときは、起動記録から順に調べる
  4. 止まっていた期間を、無条件にまとめて再実行しない
  5. 次に知りたいこと

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のエラー処理へ整理し、まず「自動起動した記録があるか」を最初の確認にしてください。

スポンサーリンク