想像一下這個場景：你精心打造了一個 n8n 自動化流程，它會在每天凌晨自動同步新訂單到你的會計系統。你滿心歡喜地以為從此可以高枕無憂，結果某天早上醒來，卻發現整個工作流因為一個暫時的網路波動或對方 API 的一次小小抽風，而在處理到第三筆訂單時就完全停擺。更糟的是，你對此一無所知，直到客戶抱怨、老闆質問，你才發現災難已經發生。
這就是缺乏「錯誤處理 (Error Handling)」的自動化流程最可怕的惡夢。在自動化的世界裡，我們必須接受一個殘酷的現實：任何可能出錯的地方，總有一天會出錯。無論是外部服務不穩定、傳入的資料格式不對，還是網路暫時中斷，這些都是日常。
一個專業的自動化流程，與一個業餘的玩具專案，最大的差別就在於是否具備處理這些「意外」的能力。n8n 提供了非常強大且直觀的錯誤處理機制，讓你能夠輕鬆地為工作流打造出「防呆」、「容錯」與「自動恢復」的能力。這篇文章將是你的 n8n 錯誤處理基礎指南，帶你精通 Continue on Fail 和 Retry on Fail 這兩大關鍵設定，讓你從此告別半夜被錯誤通知驚醒的恐懼，打造出真正堅若磐石的自動化系統。
為什麼你需要 n8n 錯誤處理？預防勝於治療
在開始設定之前，我們必須先建立一個核心觀念：錯誤處理不是一個「進階功能」，而是任何正式上線工作流的「基本要求」。你的流程隨時可能因為以下幾種常見原因而失敗：
- 外部服務問題 (External Service Issues): 你串接的第三方 API 伺服器可能正在維護、暫時無回應，或是超過了它的速率限制 (Rate Limit)。
- 非預期資料 (Unexpected Data): 傳入的資料缺少了某個必要的欄位、資料格式錯誤（例如，日期欄位變成了一段文字）、或是出現了
null或空值，導致後續的節點無法處理。 - 網路問題 (Network Issues): 你的 n8n 伺服器與目標服務之間的網路連線可能暫時不穩定或中斷。
如果沒有錯誤處理，任何一個小小的意外都可能導致整個工作流立即停止，後續所有待處理的項目都會被卡住。而一個好的錯誤處理機制，能讓你的工作流在遇到問題時，懂得如何優雅地應對，而不是粗暴地直接崩潰。
n8n 錯誤處理的核心：認識節點的「錯誤觸發器」
n8n 的錯誤處理機制，都圍繞著一個你在節點上可能沒注意過的設計：錯誤觸發器 (Error Trigger)。
仔細觀察任何一個 n8n 節點，你會發現它的右側除了有正常的綠色輸出點，當你把滑鼠移到節點下方時，還會出現一個紅色的輸出點。
- 綠色輸出點 (Success Output): 當節點成功執行後，資料會從這裡流出。
- 紅色輸出點 (Error Output): 當節點執行失敗時，錯誤的相關資訊會從這裡流出。
預設情況下，如果一個節點失敗，整個工作流會立刻停止，這個紅色的錯誤輸出點也不會被觸發。它就像一個隱藏的消防通道，只有在你手動開啟特定設定後，才會在火災（錯誤）發生時啟用。而開啟這個通道的鑰匙，就是 Continue on Fail。
關鍵設定一：Continue on Fail – 建立你的 Try/Catch 區塊
Continue on Fail 是 n8n 中實現「Try/Catch」邏輯（一種常見的程式設計錯誤處理模式）的關鍵。它的意思是：「嘗試 (Try) 執行這個節點，如果失敗了，捕獲 (Catch) 這個錯誤，不要停止整個工作流，而是將錯誤資訊送到紅色的錯誤路徑去處理。」
手把手建立 Try/Catch 模式
讓我們來建立一個最基礎的錯誤處理模式：當 HTTP Request 節點請求失敗時，自動發送一則 Slack 通知。
- 找出可能失敗的節點 (Try Block): 在我們的例子中，
HTTP Request節點是最可能因外部因素失敗的環節。 - 啟用關鍵設定:
- 點開
HTTP Request節點的設定面板。 - 切換到 Settings 分頁。
- 找到 Continue on Fail 這個選項，並將它打開 (toggle on)。
- 點開
- 建立錯誤處理流程 (Catch Block):
- 從
HTTP Request節點下方的紅色輸出點，拉出一條新的連接線。 - 將這條線連接到一個
Set節點，用來格式化我們的錯誤訊息。例如，設定一個message欄位，值為：API 請求失敗！節點: {{ $node.name }}，錯誤訊息: {{ $json.error.message }} - 再將這個
Set節點連接到一個Slack節點，將上面組合好的訊息發送到你的監控頻道。
- 從
- 建立正常流程:
- 原本從綠色輸出點拉出的連接線，則繼續處理正常的成功邏輯。
完成後，你的工作流就有了基本的容錯能力。即使 API 請求失敗，主流程雖然不會繼續，但你至少會收到一則詳細的錯誤通知，而不是讓整個工作流無聲無息地死去。
關鍵設定二：Retry on Fail – 處理暫時性錯誤的利器
有些錯誤是「暫時性」的，例如網路突然抖動一下、或是 API 伺服器瞬間負載過高。這種情況下，如果流程直接失敗並發出警報，可能會造成不必要的干擾。最好的處理方式是：稍等一下，再試一次。這就是 Retry on Fail 的用途。
設定詳解與最佳實踐
在節點的 Settings 分頁中，你會找到 Retry on Fail 的相關設定：
- On Error: 選擇
Retry on Fail。 - Retries: 你希望 n8n 在宣告失敗前，最多重試幾次。通常設定
2或3次即可。 - Retry Interval (Seconds): 每次重試之間要間隔幾秒。對於 API 請求，設定
30或60秒是個不錯的起點。
最佳實踐： Retry on Fail 非常適合用來處理暫時性的網路問題或伺服器端錯誤（HTTP 狀態碼為 5xx 系列）。但對於那些「必然會再次失敗」的錯誤，例如因為你送出的資料格式本身就有問題而導致的 400 Bad Request，開啟重試就沒有意義了。
組合技：Retry on Fail + Continue on Fail
n8n 允許你同時啟用這兩個選項，打造出最為穩健的錯誤處理模式：
- 先重試： 當節點第一次失敗時，
Retry on Fail會先生效，n8n 會根據你的設定，在間隔一段時間後自動重試。 - 重試都失敗後才報錯： 如果經過了所有重試次數後，該節點仍然失敗，這時
Continue on Fail才會接手，將最終的錯誤資訊送到紅色的錯誤處理路徑。
這個「先禮後兵」的組合，既能自動化解掉大部分的暫時性小問題，又能確保在真正發生嚴重錯誤時，你能夠收到通知並介入處理。
實戰案例：打造一個有完整錯誤處理的 API 串接流程
讓我們將所有概念組合起來，打造一個專業級的工作流。
- 目標: 每天定時從外部 API 抓取數據，經過處理後，存入資料庫。流程中的每一步都要有錯誤處理。
- 流程設計:
Cron(觸發器): 每天凌晨 3 點執行。HTTP Request(抓取 API 資料):- Settings: 啟用
Retry on Fail(3 次，間隔 60 秒)，同時啟用Continue on Fail。 - 錯誤路徑 (紅點): 連接到一個發送 Slack 通知的流程，訊息為「API 資料抓取失敗，請檢查！」。
- Settings: 啟用
Set(處理與轉換資料):- Settings: 啟用
Continue on Fail。 - 錯誤路徑 (紅點): 連接到 Slack 通知，訊息為「資料格式處理錯誤，請檢查傳入的資料！錯誤詳情：
{{$json.error.message}}」。
- Settings: 啟用
Postgres(儲存至資料庫):- Settings: 啟用
Retry on Fail(2 次，間隔 30 秒，應對資料庫暫時連線問題)，同時啟用Continue on Fail。 - 錯誤路徑 (紅點): 連接到 Slack 通知，訊息為「資料庫寫入失敗！請檢查資料庫狀態！」。
- Settings: 啟用
透過這種模組化的錯誤處理，當問題發生時，你收到的通知會非常精準，立刻就能知道是哪個環節出了問題，大幅縮短了除錯的時間。
結語
錯誤處理是劃分業餘與專業自動化的分水嶺。一個沒有錯誤處理的工作流，就像一輛沒有安全氣囊和備胎的汽車，雖然在順暢的道路上能跑，但只要遇到一點小狀況，就可能導致嚴重的後果。
今天我們學會了 n8n 錯誤處理的兩大核心利器：
Continue on Fail: 建立 Try/Catch 模式，確保流程在出錯時不會完全停擺，並能執行備用的錯誤處理邏輯。Retry on Fail: 優雅地處理暫時性的網路或伺服器問題，讓流程具備自我修復的能力。
將這兩個設定組合使用，並為你工作流中的關鍵步驟都接上錯誤處理路徑，是你為自己的自動化成果買下的最好保險。從今天起，就將「錯誤處理」納入你打造每一個工作流的標準作業流程吧！這將讓你的自動化系統，從一個脆弱的玩具，蛻變為一個值得信賴的生產力猛獸。
