n8n 剛裝好的時候很快。跑了兩三個月之後，你會發現編輯器開始卡、執行清單要載很久、有時候儲存流程要等一下。
直覺反應是資源不夠，該升級了。多數情況下不是。
30 秒總覽
| 項目 | 內容 |
|---|---|
| 為什麼會膨脹 | 每次執行的每個節點輸入輸出都存下來 |
| 什麼樣的流程最兇 | 高頻率 × 大資料量 × 節點多 |
| 症狀 | 編輯器變鈍、執行清單載很久 |
| 最有效的一招 | 成功的執行不保存或短期保存 |
| 要注意 | 清掉就沒了，別拿它當資料來源 |
它把每一次執行都存下來了
n8n 預設會記錄每一次執行的完整過程——不只是成功或失敗，而是每個節點的輸入與輸出資料。
這個設計在開發時非常好用。流程出錯，你可以點進那一次執行，看到每一步拿到什麼、吐出什麼，問題一目瞭然。
但它的成本是：一條每五分鐘跑一次的流程，一天 288 次，一個月 8,640 次。如果每次處理的資料有幾十 KB，一個月就是幾百 MB——而這只是一條流程。
什麼樣的流程膨脹最快
| 特徵 | 為什麼 |
|---|---|
| 觸發頻率高 | 筆數直接乘上去 |
| 每次處理的資料量大 | 抓回一整個 API 回應、讀整張試算表 |
| 節點多 | 每個節點的輸入輸出都各存一份 |
| 有附件或圖片經過 | 二進位資料特別佔空間 |
第三項最容易被低估。一條有十五個節點的流程，單次執行存下來的資料量是三節點流程的好幾倍——而且中間節點的資料常常是重複的。
該怎麼處理
一、設定保留期限
最直接的做法：讓 n8n 自動清掉超過一定天數的執行紀錄。
保留多久取決於你多久會回頭查。實務上七到十四天對多數人夠用——如果一條流程壞了兩週你都沒發現，那你需要的是失敗通知，不是更長的紀錄。
二、只保留失敗的紀錄
n8n 可以分別設定成功與失敗的保存策略。成功的執行你幾乎不會回去看，失敗的才有價值。
把成功的執行設成不保存或短期保存，膨脹速度會直接掉一個量級。這是投報率最高的一項調整。
三、減少不必要的資料流動
如果流程中間有一步撈回一大包資料、但後面只用到其中兩個欄位，在那一步之後加個節點只留需要的欄位。這樣不只省空間，執行也會變快。
清理之前先想一下
要提醒一件事：執行紀錄清掉就沒了。
如果你有流程是靠執行紀錄來對帳的——例如查「這筆訂單昨天到底有沒有送出去」——那清理之前要先把關鍵資訊寫到別的地方去。
比較穩的做法是不要依賴執行紀錄當資料來源。重要的結果應該主動寫進資料表，執行紀錄只當除錯工具。這樣清理就完全沒有心理負擔。
什麼情況下不用管
誠實講：如果你的流程是每天跑一兩次、資料量也小，那執行紀錄一年也長不到會影響效能的規模。這篇的內容你可以先放著。
會需要處理的訊號很具體——編輯器操作明顯變鈍、執行清單要等好幾秒、或儲存空間開始逼近方案上限。三個裡出現任何一個，先來看保留設定，不要急著升級方案。
方案是 1 vCPU／2 GB 儲存（年繳 NT$5,988，平均每月 NT$499）。2 GB 對流程本身綽綽有餘，會撐爆它的幾乎都是執行紀錄。
清理是治標，設計是治本
設保留期限能控制住空間，但更根本的做法是讓每次執行本來就不要產生那麼多資料。
三個常見的浪費：
- 整包 API 回應一路傳到底——中間加一個節點只留需要的欄位，後面每個節點的紀錄都會變小
- 用迴圈逐筆處理——每一圈都是一份紀錄，能批次處理就批次
- 除錯用的節點忘了移除——那些只是為了看中間結果而加的，上線前該拿掉
做完這三件事，紀錄量通常會掉一半以上，而且流程本身也會變快。
怎麼估你的流程會長多快
不用精算，抓個量級就夠：
每月筆數 = 觸發頻率 × 一天次數 × 20 個工作日
| 流程 | 每月執行 | 膨脹速度 |
|---|---|---|
| 每天一次的報表 | 約 20 次 | 可以忽略 |
| 每小時一次的同步 | 約 480 次 | 慢，但會累積 |
| 每 5 分鐘一次 | 約 5,760 次 | 要設保留期限 |
| Webhook 觸發的表單 | 看實際流量 | 通常不多 |
再乘上「每次處理的資料量」與「節點數量」。一條十五個節點、每次抓回整份 API 回應的流程，單次紀錄可能是三節點流程的十倍以上。
常見問題
Q：清掉執行紀錄會影響流程運作嗎？
不會。紀錄是給人看的，流程本身不依賴它。唯一的例外是你拿它當對帳依據——那種情況該把關鍵資訊主動寫進資料表，不要依賴紀錄。
Q：保留多久比較好？
七到十四天對多數人夠用。判斷方式是問自己「一條流程壞掉，我多久會發現」——如果答案是兩週，那保留期限比兩週短就沒意義；但如果答案是兩週，你真正需要的是失敗通知，不是更長的紀錄。
Q：可以只保留失敗的嗎？
可以，而且這是投報率最高的一項調整。成功的執行你幾乎不會回去看，失敗的才有價值。設定之後膨脹速度通常會掉一個量級。
Q：編輯器變慢一定是這個原因嗎？
不一定，但這是最常見的。可以先看儲存空間的使用量——如果明顯偏高而流程本身很小，那多半就是紀錄。
Q：資料量大的流程有別的解法嗎？
有。在流程中間加一個節點只保留需要的欄位，不要讓整包 API 回應一路傳到最後。這樣不只省空間，執行也會變快。
什麼時候該把它當成警訊
紀錄膨脹本身是正常的，但它有時候是另一個問題的症狀。
如果某條流程的紀錄量明顯高於其他流程，值得看一眼：是不是它被重複觸發了？Webhook 被外部重試？排程設得比需要的密？
那種情況清理紀錄只是把症狀掃掉，觸發頻率本身才是要處理的。空間長得比預期快，通常代表流程跑得比你以為的多。
資料來源與延伸連結
n8n 的節點與計費方式更新頻繁，以下是查證用的一手來源：
- n8n 官方文件
- n8n 官方定價——雲端版方案與額度
- n8n 原始碼與版本紀錄——授權條款以此為準
延伸閱讀
- n8n 常見問題：資源上限、Webhook 網址與社群節點
- n8n Webhook 與第三方串接教學
- n8n 加 NocoDB：把自動化的資料留在自己手上
- 自架 n8n 比較便宜嗎：把時間算進去的成本表
- RoamerHost n8n 託管方案
想找人幫你做？
這些流程要是不想自己搭，或是規模大到需要有人一起規劃，浪花科技（RoamerHost 的母公司）承接企業流程自動化與 AI Agent 的委託開發：
n8n
