初心者向け
n8n Schedule Triggerの使い方:ワークフローを決まった時刻に自動実行する
n8nのSchedule Triggerで、ワークフローを定期実行する方法を解説します。日本で使うなら必ず確認すべきタイムゾーン設定と、n8nを止めていた間の実行がどうなるかまで。
公開
動作確認: — n8n 2.36.8 / Schedule Trigger ノード v1.4
ワークフローを決まった時刻に自動で動かすためのトリガーが Schedule Trigger です。 これまでは手動で実行ボタンを押していたものが、放っておいても動くようになります。
この記事は前半がn8n を触ったことがない人向けで、毎朝決まった時刻に動くワークフローを 作るところまでを通します。後半は基本操作ができる人向けに、 日本で使うなら必ず確認すべきタイムゾーンと、n8n を止めていた間の実行がどうなるかを扱います。
設定項目は Schedule Trigger ノード v1.4 の定義を直接確認して書いています。
Schedule Trigger は何をするものか
ワークフローの先頭に置いて、決まったタイミングで実行を始めるノードです。
これまでの記事では Manual Trigger(手動実行)を使っていました。これを Schedule Trigger に置き換えると、自分で押さなくてもワークフローが動きます。
トリガーは先頭にしか置けません。途中に入れて「ここで待つ」ような使い方はできません。
実際に定期実行させてみる
前回までに作った、天気を取ってきて雨かどうか判定するワークフローを、 毎朝自動で動くようにします。
手順
- ワークフローから Manual Trigger を削除する
- Schedule Trigger を追加し、後ろのノードにつなぐ
- Trigger Interval で
Daysを選ぶ - Days Between Triggers を
1、Trigger at Hour を7am、Trigger at Minute を0にする - キャンバスに戻り、画面右上の Publish を押す

最後の Publish を忘れないでください。 これを押すまで、どれだけ設定しても 自動では動きません。手動実行のテストは通るのに定期実行されない、という状態になります。
設定画面の上部にも、そのことが書かれています。
This workflow will run on the schedule you define here once you publish it.
なお、テストしたいときはキャンバスに戻って execute workflow を押すか、
このノードの出力パネルにある Test this trigger を使います。
実行のタイミングの選び方
Trigger Interval で6種類から選べます。
| 種類 | 指定できること | 既定値 |
|---|---|---|
| Seconds | 何秒おき(1〜59) | 30秒 |
| Minutes | 何分おき(1〜59) | 5分 |
| Hours | 何時間おき(1〜23)+ 毎時何分 | 1時間・0分 |
| Days | 何日おき(1〜31)+ 何時何分 | 1日・0時0分 |
| Weeks | 何週おき+曜日+何時何分 | 1週・日曜・0時0分 |
| Months | 何ヶ月おき+何日+何時何分 | 1ヶ月・1日・0時0分 |
複数の間隔を登録できます。 設定画面の + Add Rule で追加すると、 「平日の朝9時」と「土曜の朝11時」のように、条件の違う実行を1つのノードにまとめられます。
タイムゾーンを必ず確認する
日本で使うなら、ここが最重要です。
Schedule Trigger の「7時」が何時を指すかは、n8n のタイムゾーン設定で決まります。
そして公式ドキュメント
によれば、セルフホスト版の既定は America/New_York です。
何も設定せずに「7:00」と指定すると、日本時間では前夜に動きます。 「朝のはずが夜に動いた」「1日ずれている」という現象の原因はほぼこれです。
どこで決まるのか
設定は2段階で、ワークフロー個別の設定が優先されます。
- ワークフロー単位 — ワークフローを開き、右上の「…」から Settings → Timezone
- インスタンス単位 — セルフホストなら環境変数
GENERIC_TIMEZONE、n8n Cloud なら管理画面
n8n Cloud はサインアップ時にタイムゾーンを推定しますが、失敗した場合は GMT になります。
設定画面の表示に注意
ここが実際に引っかかった点です。
ワークフローの Settings を開くと Timezone が表示されますが、それが 「このワークフローに設定された値」なのか「インスタンス設定を引き継いだ値」なのかは、 画面からは区別できません。
自分の環境で確認したところ、Settings の表示は Asia/Tokyo でした。
しかし API でワークフローの設定を見ると、timezone の項目自体が存在しませんでした。
"settings": { "executionOrder": "v1", "availableInMCP": true, "binaryMode": "separate" }
つまりワークフローには何も設定されておらず、インスタンス側の
GENERIC_TIMEZONE=Asia/Tokyo を引き継いでいただけでした。
これが何を意味するかというと、インスタンスの設定を変えた瞬間、 「個別に設定したつもりだった」ワークフローの実行時刻が全部ずれるということです。 時刻がずれては困るワークフローは、明示的にワークフロー単位で設定しておくのが安全です。
時刻を指定するトリガーを作ったら、まず1回動かして実際の時刻を確認してください。 設定画面の見た目だけでは、ずれているかどうかも、どこで設定されているかも分かりません。
月末の指定に注意
Months を選ぶと「毎月何日」を指定できますが、ノードの定義にこう書かれています。
その月にその日が無い場合、このノードは実行されません。
たとえば 31日を指定すると、2月・4月・6月・9月・11月は実行されません。 「月末に集計する」つもりで31日を指定すると、月によって動かなくなります。
月末に動かしたいなら、翌月1日に実行して前月を対象にする方が確実です。
曜日の番号
Weeks で曜日を選ぶとき、内部では数値で管理されています。
既定値は 0 で、これは日曜日です。
画面上は曜日名で選べるので通常は意識しませんが、 設定をコピーしたりJSONを直接編集したりするときは、0が日曜であることを覚えておくと迷いません。
n8n を止めていた間の実行はどうなるか
実行予定の時刻に n8n が動いていなかった場合の挙動は、If Execution Is Missed という設定で
決まります。既定は skip(実行しない) です。
つまり、PCを閉じていた間の実行は後から取り戻されません。
ほかに、遅れて実行する選択肢もあります。どれを選ぶかは用途によります。
- 毎朝の通知 — 過ぎた分を後から送られても困るので
skipでよい - 日次のデータ集計 — 抜けが困るので、取り戻す設定にするか、別途チェックする仕組みが要る
あわせて Max Execution Delay(どれだけ遅れたら「逃した」とみなすか)も設定できます。 既定は 0 で、これはインスタンス側の設定に従うという意味です。
ローカルのPCで n8n を動かしている場合、この挙動は特に重要です。 PCをスリープさせている間の実行は、既定では失われます。
Cron で細かく指定する
Custom (Cron) を選ぶと、Cron 式で指定できます。
フォーマットは以下で、秒の欄が先頭にあり、省略できます。
([秒]) [分] [時] [日] [月] [曜日]
一般的な Cron は5つの欄(分・時・日・月・曜日)ですが、n8n は先頭に秒を足した6欄も 受け付けます。他所からコピーした Cron 式が意図と違う時刻に動く場合は、 欄がずれていないか確認してください。
うまくいかないときの切り分け
- Publish したか — 押すまで自動では動かない。手動実行だけは通るので気づきにくい
- タイムゾーンが合っているか — 設定していなければ日本時間ではない。 画面の表示は継承値かもしれない
- 1回動かして実際の時刻を見る — 設定画面の見た目では判断できない
- 月末・曜日の指定 — 存在しない日を指定していないか
- n8n が起動していたか — 止まっていた間の実行は既定では取り戻されない
次に読む
- n8n IFノードの使い方 — 取得したデータで処理を分岐させる
- n8n HTTP Requestノードの使い方 — 外部のAPIからデータを取ってくる
- コアノードの一覧 — ほかのよく使うノード