n8n 的 Schedule Trigger 節點讓工作流按固定時間自動執行，不需要外部呼叫。它支援三種設定方式——固定間隔（每 N 分鐘）、指定時刻（每天/每週幾點）、以及完整的 Cron 表達式——其中時區設定與 self-hosted 的執行模式是最容易被忽略卻最常出問題的地方。

很多自動化需求其實都是「定時做某件事」：每天早上把昨天的訂單整理成報表、每小時檢查一次庫存、每週一寄出週報。這些都不需要外部事件來觸發，只要「時間到了就跑」。在 n8n 裡，這由 Schedule Trigger 節點負責，它是整個排程類工作流的起點。

本文是 n8n 入門系列「觸發器」主題的支柱文章。如果你的需求是「外部事件發生時即時觸發」（例如收到付款、表單送出），那要看的是 Webhook，可參考n8n Webhook 觸發器設定入門。

Schedule Trigger 與舊版 Cron 節點

n8n 早期有獨立的 Cron 節點，新版已整合進 Schedule Trigger。如果你看舊教學提到 Cron 節點，功能是一樣的，現在統一在 Schedule Trigger 裡操作。一個工作流的開頭放上它，就代表「這條流由時間驅動」。

Schedule Trigger 在編輯器裡點「Test workflow」時會立刻跑一次方便你測試，但真正的定時執行只有在工作流被 Activate（啟用）之後才會生效——這是新手第一個卡點：設好了排程卻發現沒動，多半是忘了把右上角開關打開。

三種設定方式

打開 Schedule Trigger，Trigger Interval 下拉選單決定你用哪種方式排程。

最直覺：每隔多少時間跑一次。

適合「頻率固定、不在乎是幾點幾分」的輪詢型任務。注意間隔太短（例如每幾秒）會大量消耗資源，self-hosted 要評估機器負載。

需要「每天早上 9 點」這種精確時刻時用這種。選 Days，就能指定 Trigger at Hour 與 Trigger at Minute；選 Weeks 還能多選星期幾。

這是最常用的模式，多數「每日/每週例行任務」都靠它。

需要複雜規則時（例如「週一到週五每小時、但只在上班時間」），選 Custom (Cron)，直接寫 Cron 表達式。

n8n 用的是 6 欄位格式（含秒）：

秒 分 時 日 月 星期

幾個常用範例：

* 代表「任何值」，*/N 代表「每 N 個單位」，1-5 是範圍，1,3,5 是清單。寫不出來時，用線上的 crontab 產生器對照，再貼回 n8n 驗證。

排程「準時跑卻晚了 8 小時」幾乎都是時區問題。Schedule Trigger 的執行時間依據的是 n8n 實例的時區設定，不是你電腦的時區。

GENERIC_TIMEZONE=Asia/Taipei
TZ=Asia/Taipei

GENERIC_TIMEZONE 控制排程與日期節點的時區，TZ 控制系統與 log 的時區，兩個都設才不會出現「介面顯示對、實際跑錯」的詭異狀況。改完要重啟 n8n 才生效。

self-hosted 用 Docker 跑 n8n 時，排程能不能準時觸發，取決於 n8n 主進程是否持續運行。幾個重點：

容器要設 restart: always（或 unless-stopped），機器重開後 n8n 會自動拉起來，排程才不會斷。
如果你用 queue 模式（多 worker 架構），Schedule Trigger 由 main 實例負責觸發，worker 負責執行，要確認 main 實例有正常運行。
機器休眠、容器被 OOM 砍掉，排程就會漏跑——這是 self-hosted 比 Cloud 多出來的維運責任。

照順序檢查，九成問題都在前三項：

Schedule Trigger 是 n8n 所有定時任務的起點：簡單需求用固定間隔或指定時刻，複雜規則用 Cron 表達式。但真正讓人踩雷的不是設定本身，而是時區與 self-hosted 的進程穩定性——這兩件事顧好，排程才會真的「每天準時跑」。

設好排程後，下一步通常是處理觸發後的資料流。建議搭配n8n Set 與 Merge 節點：整理與合併資料流的正確方式，或回到n8n 核心節點完全攻略補齊整體節點地圖。