N8N 執行失敗自動重試：設計穩健工作流的錯誤補償機制

工作流昨天還好好的，今天早上一看——失敗了。點進去一查，原因是某個 API 那一秒剛好回了 503。服務本身沒問題，只是那一瞬間抖了一下，但你的整條流程就這樣斷在半路，後面該做的事全沒做。

這種「明明重跑一次就會成功」的失敗，佔了實務上工作流出錯的一大半。穩健的工作流不該因為一次暫時性抖動就整個掛掉，而是要能自己重試、自己補償、出大事才通知人。這篇就教你怎麼設計這套機制。

三層防護的整體思路

把錯誤處理想成三道防線，由內而外：

1. 節點層自動重試：單一節點失敗，當場重試幾次，多數暫時性錯誤在這層就解決。
2. 流程層分支補償：重試還是失敗，走另一條路（降級處理、記錄、放進待處理佇列）。
3. 工作流層錯誤捕捉：整條流程真的炸了，觸發錯誤工作流去通知人、記 log。

大部分人只做了第三層（出錯收通知），結果每次小抖動都收到一封警報，久了就麻痺。重點是把前兩層先做好，讓真正需要人介入的事才浮上來。

第一層：節點層的 Retry On Fail

這是最簡單、CP 值最高的一招，而且內建在每個節點裡，不用加任何節點。

點開任一個節點，到 Settings 分頁，打開 Retry On Fail。打開後可以設定：

• Max Tries：最多重試幾次（含第一次，通常設 3～5 次）。
• Wait Between Tries (ms)：每次重試之間等多久。

關鍵在等待時間怎麼設。 暫時性錯誤（503、timeout、rate limit）需要給對方喘息的時間，所以間隔別設太短。常見的做法是設個 1000～5000ms 起跳。如果你打的 API 有明確的速率限制，間隔要設得比限制窗口更寬，否則重試只是繼續撞牆。

哪些節點該開重試？

• ✅ 呼叫外部 API 的 HTTP Request 節點。
• ✅ 連資料庫、第三方服務（Slack、Gmail、Sheets）的節點。
• ❌ 純資料轉換的 Code / Set / Filter 節點——這些失敗是邏輯錯誤，重試一百次也一樣錯，重試只會拖慢發現問題的速度。

重試只對「同樣的輸入，再試一次有機會成功」的操作有意義。邏輯錯誤不該靠重試掩蓋。

第二層：用 Error Output 做流程補償

節點重試幾次還是失敗怎麼辦？預設行為是整個工作流停下來、標記失敗。但有時候你希望「失敗了也別停，走 Plan B」。

n8n 的節點支援 On Error 行為設定（在節點 Settings 裡），有三種選擇：

• Stop Workflow（預設）：失敗就停。
• Continue：失敗也繼續，把錯誤資訊往下傳。
• Continue (using error output)：失敗的 item 走一條獨立的錯誤輸出分支。

第三種最實用。設成 Continue using error output 後，節點會多出一個紅色的錯誤輸出口。成功的 item 走正常那條，失敗的走錯誤那條。你就能對失敗的資料做補償：

• 寫進一張「待重處理」資料表，晚點批次重跑。
• 改用備援的 API 或降級方案。
• 記錄詳細錯誤後，讓流程繼續處理剩下沒問題的資料，而不是一筆失敗害全部停擺。

這層的精神是：單筆失敗不該污染整批。 1000 筆裡有 3 筆失敗，應該是「成功 997 筆、3 筆進待處理」，而不是「整批回滾、什麼都沒做」。

更完整的分支設計與死信佇列（DLQ）做法，可以參考 n8n 錯誤處理與重試機制 和 n8n 工作流錯誤處理模式。

第三層：Error Trigger 全域捕捉

前兩層處理「預期內」的失敗。但總有預期外的——程式碼 bug、認證過期、整個服務掛掉。這時你需要一個全域的安全網，確保「任何工作流出大事，你一定會知道」。

做法是建一個獨立的錯誤處理工作流：

1. 新建一個工作流，第一個節點放 Error Trigger。
2. 接上通知節點（Slack、Email、Telegram），把錯誤訊息、出錯的工作流名稱、節點名稱、執行連結整理進通知內容。
3. 回到你要監控的工作流，進 Settings → Error Workflow，指定剛剛那個錯誤工作流。

設定好之後，被監控的工作流只要執行失敗，就會自動觸發錯誤工作流。Error Trigger 會帶入 $json.execution 和 $json.workflow 等資訊，你可以組出一則清楚的警報，例如：

🚨 工作流「每日訂單同步」在節點「Push to ERP」失敗 錯誤：Request failed with status 401 時間：2026-06-18 09:14 查看執行：<執行連結>

一個錯誤工作流可以被多個工作流共用，不用每條都重做。

把三層組起來：一個實際範例

假設你有個工作流，每小時把新訂單推到外部 ERP：

1. HTTP Request（推訂單到 ERP）:開啟 Retry On Fail，3 次、間隔 3000ms。→ 擋掉九成的暫時性抖動。
2. 同一節點 On Error 設成 Continue using error output。→ 重試後仍失敗的訂單，走錯誤分支寫進「失敗訂單」資料表，等下一輪批次重推，不影響其他訂單。
3. 工作流 Settings 指定 Error Workflow。→ 萬一是認證過期之類的系統性問題（每筆都失敗），錯誤工作流發 Slack 通知你立刻處理。

三層各司其職：第一層吃掉雜訊、第二層隔離單筆失敗、第三層只在真出事時找人。這樣你的 Slack 不會被假警報轟炸，真正的問題也不會被漏掉。

設計時的幾個提醒

• 重試要冪等：如果重試的操作會「重複寫入」（例如重複建立訂單），先確認對方 API 支援冪等鍵（idempotency key），否則重試 3 次可能建出 3 筆。
• 別把重試當萬靈丹：如果某個 API 經常失敗到要靠重試 5 次才成功，那是該查根因（速率限制？認證？），不是調高重試次數。
• 錯誤訊息要留得夠細：補償分支記錄錯誤時，把完整的錯誤內容和原始輸入都存下來，否則事後根本不知道為什麼失敗。
• 測試失敗路徑：別只測成功的情況。故意餵錯資料、或暫時改錯 API 網址，確認三層機制真的有照你設計的方式運作。

關於怎麼安全地測試這些失敗路徑而不弄壞真實資料，可以接著看 N8N 測試模式完整教學。

小結

穩健的工作流不是「不會失敗」，而是「失敗了能自己站起來」。

記住這三層：節點重試吃雜訊、錯誤分支隔離單筆、Error Trigger 抓大事。 多數人只做了最外層的通知，結果被假警報淹沒；把內兩層做好，你的工作流才會真的可靠，而你也才能安心讓它在半夜自己跑。

想進一步把工作流跑得又穩又快，搭配 N8N 工作流效能優化 一起看。