在昨天的 Day 11 中，我們成功串接 Telegram Bot 完成了任務落地後的即時推播回報。然而，真實的自動化環境往往充滿不可預期的變數：例如 Dify API 連線逾時、模型回傳了非預期的 Markdown 符號導致 JSON 解析失敗，或是 Notion 伺服器短暫波動等。

今天我們要學習如何為 n8n 打造「容錯保護網」，透過錯誤捕獲機制（Error Trigger），在流程失敗時即時通報，避免系統靜默中斷！

為什麼需要專門的錯誤處理機制？

預設情況下，當 n8n 任一節點執行失敗時，整個 Workflow 會直接中斷，且不會觸發後續的任何節點。如果沒有監控機制：

1. 靜默失敗（Silent Failure）：使用者以為待辦事項已存入 Notion，實際上卻卡在 API 報錯，導致重要事項遺漏。
2. 排錯成本高：必須手動登入 n8n 後台翻查 Executions 紀錄，才能確認哪一次執行出錯。
3. 缺乏重試與備援：無法在關鍵 API 發生網路波動時自動重試。

核心實作步驟說明

1. 節點內建重試與忽略錯誤（Node Settings）

對於容易發生網路抖動的節點（例如 HTTP Request 呼叫 Dify）：

• 點開 HTTP Request 節點，切換至頂部的 Settings 分頁。

• 開啟 Retry On Fail（失敗時自動重試）：

• Max Tries：設為 3。

• Wait Between Tries (ms)：設為 2000（間隔 2 秒重試一次）。

• 若該節點允許非致命失敗，亦可開啟 Continue On Fail，讓流程繼續往下走。

2. 建立全域錯誤處理專用工作流（Error Workflow）

在 n8n 中，最標準的高可用架構是建立一條獨立的「警報專用工作流」：

• 新增一個全新的 Workflow，命名為 [System] Error Handler。
• 點擊新增起始節點，搜尋並選擇 Error Trigger。
• 每當其他工作流發生未捕獲的錯誤時，此節點會自動啟動，並接收到以下關鍵偵錯資訊：
• {{ $json.execution.id }}：失敗的執行序 ID。
• {{ $json.workflow.name }}：出問題的工作流名稱。
• {{ $json.execution.error.message }}：具體的錯誤訊息。

3. 串接 Telegram 失敗警報推播

• 在 Error Trigger 後方連線一個 Telegram 節點。
• 設定發送訊息給管理員：

🚨 *[n8n 系統警報] 流程執行失敗！*

⚙️ *失敗工作流*：{{ $json.workflow.name }}
🆔 *Execution ID*：#{{ $json.execution.id }}
❌ *錯誤原因*：`{{ $json.execution.error.message }}`

🔗 [點此進入 n8n 查看錯誤記錄](http://localhost:5678/workflow/{{ $json.workflow.id }}/executions/{{ $json.execution.id }})

4. 綁定主工作流並觸發測試

• 回到我們先前建立的任務主工作流（Day 10 的端到端流程）。
• 點擊畫布左上角工作流名稱旁的 Workflow Settings（齒輪圖示）。
• 在 Error Workflow 欄位中，選取剛建立好的 [System] Error Handler 並儲存。
• 故意製造錯誤測試：例如暫時將 Notion Token 改錯或關閉網路，發送一次請求，確認 Telegram 是否立刻收到紅色警報推播！

今天我們為自動化管線裝上了安全氣囊，使整個任務提煉系統具備生產環境（Production-ready）的穩定度。明天「Day 13」我們將進入更進階的場景——「多輪對話與上下文延續」，讓 Dify 能夠記憶先前的任務對話，支援追加修改與即時刪改待辦事項！