n8nのSchedule Triggerを理解する｜定期実行とTimezoneの基本

n8nでは、外部からrequestが届くのを待つだけでなく、決めた間隔や時刻にWorkflowを自動実行できます。その入口になるのがSchedule Trigger nodeです。

指定時刻になる
→ Schedule Triggerが起動
→ Workflowを実行
→ 結果をExecutionsへ記録

毎朝の集計、週次レポート、一定間隔のAPI確認などに使えます。ただし、画面で「9:00」と設定しても、timezoneが想定と違えば別の時刻に動きます。

Schedule Triggerでは、scheduleとtimezoneを一組として設計することが重要です。

今日の到達点

• Schedule Triggerの役割を説明できる
• interval指定とCustom Cronを使い分けられる
• WorkflowのPublishが必要な理由を理解できる
• Workflow timezoneとinstance timezoneの優先関係を説明できる
• 時刻ずれ、二重実行、実行漏れを確認する方法を理解できる

Schedule Triggerとは何か

Schedule Triggerは、固定された間隔または時刻を条件にWorkflowを開始するTrigger nodeです。

時間というイベント
→ Schedule Trigger
→ データ取得
→ 加工・判定
→ 通知・保存

Schedule Triggerが出力するのは、業務データそのものではありません。定刻になったことを合図に後続nodeを起動し、後続のHTTP Requestやサービスnodeなどが必要なデータを取得します。

Manual Triggerとの違いは、開始操作を人が行うか、schedulerが行うかです。

Publishしないと本番scheduleは動かない

Schedule Triggerを設定してeditorから手動実行できても、それだけでは定期実行されません。

現在のn8n公式ドキュメントでは、Schedule Triggerを本番で動かすにはWorkflowを保存してPublishする必要があります。

Scheduleを設定
→ 手動でnodeを確認
→ WorkflowをPublish
→ scheduleが登録される
→ 設定時刻にproduction execution

古い記事や環境では、Active toggleをONにすると説明される場合があります。現在のUIではPublish／Publishedが中心です。使用環境にActive表記がある場合も、「本番triggerが自動起動できる状態か」という観点で確認します。

Published後にDraftのscheduleを変更しただけでは、本番scheduleへ反映されません。変更を反映するには新しいversionをPublishします。

Trigger Intervalの種類

Schedule TriggerではTrigger Rulesを追加し、実行条件を設定します。現在の公式仕様では、次のintervalを選択できます。

• Seconds
• Minutes
• Hours
• Days
• Weeks
• Months
• Custom（Cron）

複数のTrigger Rulesを追加し、同じWorkflowを異なるscheduleで起動することもできます。

SecondsとMinutes

短い間隔で繰り返す設定です。

Every 30 seconds
Every 5 minutes

実習では動作を観察しやすい一方、本番で短い間隔にするとexecution数、API rate limit、重複処理、課金へ影響します。

Hours

何時間ごとに実行するかに加え、何分に起動するかを指定します。

Hours Between Triggers: 6
Trigger at Minute: 30

この例は6時間ごとの30分に実行されます。

DaysとWeeks

Daysでは、何日ごとか、何時何分に実行するかを指定します。

Weeksでは、週の間隔、曜日、時刻を設定できます。平日の決まった曜日にレポートを作る場合などに向いています。

Months

月の間隔、日、時刻を指定します。

「毎月31日」と設定した場合、31日が存在しない月には実行されません。月末処理では、固定日を指定するだけで要件を満たすか確認が必要です。

intervalはPublish時点を基準にする場合がある

「毎日9:00」のような時刻指定と、「2時間ごと」のような経過間隔は考え方が異なります。

現在の公式ドキュメントでは、scheduleの変更をPublishすると、新しいintervalはPublishした時点から始まると説明されています。

たとえば2時間間隔のversionを11:30にPublishした場合、次回が13:30になる可能性があります。

固定時刻：毎日 09:00
経過間隔：Publishから2時間ごと

「時刻に合わせたいのか」「前回から一定時間ごとに動かしたいのか」を先に決めます。

Custom Cronの基本

標準のintervalで表しにくいscheduleにはCustom（Cron）を使います。

代表例は次のとおりです。

n8nのCron expressionは、一般的な5fieldに加え、先頭へ秒を指定した6fieldも利用できます。

(second) minute hour day-of-month month day-of-week

10秒ごとの例です。

*/10 * * * * *

秒fieldは省略できます。外部のCron生成ツールを使う場合は、n8nが受け付けるfield数とsyntaxに合っているか確認してください。

Cron内でvariablesを使う場合、その値はWorkflowをPublishした時点で評価されます。後からvariableだけを変更してもscheduleは更新されないため、Unpublishして新しいversionをPublishします。

現在のintervalとCron仕様は、n8n公式のSchedule Trigger nodeで確認できます。

Timezoneの優先関係

Schedule Triggerが使うtimezoneには優先順位があります。

Workflow timezoneが設定済み
→ Workflow timezoneを使用

Workflow timezoneが未設定
→ n8n instance timezoneを使用

Workflow固有のtimezoneは、canvas右上のメニューからWorkflow settingsを開いて設定します。個別設定がない場合はinstance timezoneが使われます。

n8n Cloud

Cloudでは、instanceのTimezoneを管理画面から変更できます。

公式ドキュメントでは、登録時にownerのtimezoneを検出し、検出できない場合はGMTへfallbackすると説明されています。

self-hosted

self-hostedでは、GENERIC_TIMEZONE環境変数でinstance timezoneを設定できます。公式ドキュメント上のdefaultはAmerica/New_Yorkです。

日本時間で運用する例は次のとおりです。

GENERIC_TIMEZONE=Asia/Tokyo

OSやcontainerのtimezoneを日本へ変更しただけで、n8nのscheduleも必ず日本時間になるとは判断しません。n8nのWorkflow settingsとinstance設定を直接確認します。

詳細はn8n公式のTimezone and localizationで確認できます。

UTC+9とAsia/Tokyoの違い

日本は現在、夏時間を採用していないため、Asia/Tokyoは年間を通してUTC+9として扱われます。

一方、America/New_Yorkなどの地域timezoneはDST、つまり夏時間によってUTCとの差が変わります。現地時刻9:00を維持したい場合は、固定offsetではなく地域timezoneを指定する設計が基本です。

海外拠点を扱う場合は、次を明確にします。

• どの地域の「朝9時」か
• DST切り替え日に同じ時刻が存在しない、または重複する可能性を許容するか
• 記録時刻をlocal timeとUTCのどちらで保存するか

日本国内だけのWorkflowでも、instance defaultがNew Yorkのままなら時刻がずれます。「日本にはDSTがないから安全」ではなく、timezone設定そのものを確認してください。

時刻ずれを調べる順番

Schedule Triggerが想定時刻に動かない場合は、次の順番で確認します。

WorkflowがPublishedか
→ Workflow timezoneは何か
→ instance timezoneは何か
→ Trigger Ruleの時刻と曜日
→ Cronのfield数とsyntax
→ 変更後のversionをPublishしたか
→ Executionsの開始時刻

予定時刻と実行時刻は、感覚ではなく具体的な値で記録します。

workflow_timezone: Asia/Tokyo
instance_timezone: Asia/Tokyo
scheduled_local_time: "2026-09-20 20:05:00"
actual_execution_time: "実習で確認"
offset_seconds: "実習で計算"

Workflow固有のtimezone設定は、n8n公式のWorkflow settingsで確認できます。

二重実行を防ぐ

Schedule Triggerに複数のTrigger Rulesを設定すると、同じ時刻に条件が重なる可能性があります。

また、複数Workflowへ同じ業務処理を設定した場合も、処理が二重になります。

確認項目は次のとおりです。

• Trigger Rulesが同じ時刻に重複していないか
• 古いWorkflowもPublishedのまま残っていないか
• executionが2件あるのか、1 execution内で2 itemsを処理したのか
• 再実行しても同じデータを二重登録しないか
• 日付や一意IDで処理済みを判定できるか

重要な登録や通知では、「scheduleは一度しか発火しないはず」と仮定するのではなく、同じ処理が再度呼ばれても結果を壊さない設計を検討します。

実行漏れと停止時間

instance停止中に予定時刻を過ぎた場合、通常のin-memory schedulerでは停止中のexecutionが後からすべて自動実行されるわけではありません。

現在の公式ドキュメントには、durable scheduler使用時のIf Execution Is Missedやgrace periodも記載されています。

ただし、この機能はn8n 2.36以降に追加されたSchedule Triggerとdurable schedulerが対象です。環境やn8n versionによって表示されない場合があります。

初心者の段階では、次を先に決めます。

• 停止中の処理を捨ててよいか
• 復旧後に最新1件だけ実行する必要があるか
• 実行漏れを別の監視で検知するか

最小Workflowで確認する

実習では、外部サービスへ書き込まずにexecution時刻だけを観察します。

Schedule Trigger
→ Edit Fields

Edit Fieldsで次のような確認用fieldを追加します。

{{ $now.toISO() }}

field name: observed_at
type: String

短いintervalを設定し、Workflow timezoneを確認してPublishします。Executionsに記録された開始時刻とobserved_atを比較してください。

確認後は、短い試験scheduleをそのままPublishedにしないよう、Unpublishするか本来の間隔へ変更して再Publishします。

よくある失敗

Draftでscheduleを変更しただけ

Published versionは以前のscheduleで動き続けます。変更後のversionをPublishしたか確認します。

instance timezoneを想定だけで判断した

PCの時計やbrowser表示が日本時間でも、n8nのinstance timezoneが同じとは限りません。

Workflow settingsとCloud管理画面、またはGENERIC_TIMEZONEを確認します。

月末を31日指定だけで表現した

31日がない月にはtriggerされません。「月末」という業務要件なら、別の条件判定を組み合わせる設計を検討します。

短い試験intervalを戻し忘れた

数秒・数分ごとの試験設定を放置すると、execution、API call、通知が増え続けます。実習後の停止または再設定をチェックリストへ含めます。

Cronの5fieldと6fieldを混同した

先頭の秒fieldを含むかを確認し、n8n公式の例と照合します。

外部ツールで検証するときは、秒fieldを除いた形での確認が必要な場合があります。Cron errorや時刻ずれの確認方法は、n8n公式のSchedule Trigger common issuesにもまとめられています。

実務での考え方

定期実行は「何時に動くか」だけでなく、運用契約として整理します。

schedule:
  expression: "0 9 * * 1-5"
  timezone: "Asia/Tokyo"
  expected: "平日09:00 JST"

operation:
  duplicate_safe: true
  missed_execution_policy: "alert"
  owner: "workflow operator"

schedule、timezone、重複時の扱い、停止時の扱い、監視方法をセットで残すと、環境移行や担当変更後も意図を復元できます。

今日の実習で確認すること

• Schedule Triggerで検証しやすい短いintervalを設定する
• Workflow timezoneとinstance timezoneを確認する
• WorkflowをPublishしてproduction executionを待つ
• 予定時刻とExecutionsの実行時刻を比較する
• 同一時刻に二重executionが発生していないか確認する
• schedule変更後に再Publishが必要なことを確認する
• 実習後に短いscheduleを停止または変更する

まとめ

Schedule Triggerは、指定したintervalまたは時刻でWorkflowを自動起動するTrigger nodeです。

scheduleを定義
→ timezoneを明示
→ WorkflowをPublish
→ Executionsで実時刻を確認
→ 重複・漏れを監視

Workflow timezoneが設定されていればそれを優先し、未設定ならinstance timezoneを使います。Draftのschedule変更は本番へ自動反映されないため、新しいversionのPublishが必要です。

正確な定期実行は、Cron expressionだけでは完成しません。timezone、Publish状態、重複防止、停止時の扱いまで確認して、運用できるscheduleにします。

参考資料

• n8n公式：Schedule Trigger node
• n8n公式：Schedule Trigger common issues
• n8n公式：Configure workflow settings
• n8n公式：Timezone and localization
• n8n公式：Set your Cloud timezone