雲端方程式 Cloud F1 F1

n8n 核心

n8n 錯誤處理工作流｜自動偵測與通知機制

· 約 18 分鐘閱讀 · Alex Hsieh

更新於 2026年2月11日

n8n 錯誤處理工作流

📥 工作流 JSON 下載：GitHub 範例庫 ｜ 💬 社群討論：Skool 雲端方程式 Cloud F1

專業導讀

你有沒有遇過這種情況？辛辛苦苦設定好一個 n8n 自動化工作流，上線後以為可以安心睡覺，結果第二天發現昨晚的資料沒進來、客戶的訂單沒處理、LINE 通知沒發出去——而且你完全不知道什麼時候出錯的，也不知道是哪個節點掛掉的。這就是為什麼錯誤處理機制這麼重要。

今天要跟大家分享的是：怎麼用 n8n 的 Error Workflow（錯誤處理工作流）功能，打造一個自動偵測、即時通知、完整記錄的監控系統。讓你的自動化不只是「能跑」，而是「穩定跑」，出問題能第一時間知道、快速修復。

你將學到

  • n8n Error Trigger 和 Error Workflow 的完整設定流程
  • 三大錯誤通知方法（LINE、Email、Google Sheet）的適用時機
  • 如何收集完整的錯誤資訊（工作流名稱、失敗節點、錯誤訊息、執行時間）
  • 避免通知轟炸的冷卻時間設計策略
  • 錯誤日誌的長期追蹤與趨勢分析方法
  • 重試機制與自動恢復的進階設定

🎯 什麼是 n8n 錯誤處理工作流？

n8n 錯誤處理工作流（Error Workflow）就是一個專門用來處理其他工作流執行失敗時的自動化流程。當任何工作流發生錯誤時，Error Workflow 會自動被觸發，收集錯誤資訊、發送通知、記錄日誌，讓你快速掌握問題並修復。

簡單來說，它就像是你的自動化系統的「保全警報」——正常運作時你不會注意到它的存在，但一旦有狀況，它會第一時間通知你，並且把現場證據都保存下來。

很多人問我：「Alex，n8n 不是本身就有重試功能嗎？為什麼還需要 Error Workflow？」這是個好問題。n8n 的重試功能（在每個節點設定裡可以找到）確實可以自動重試失敗的節點，但它解決的是「暫時性錯誤」（例如 API 暫時無回應）。如果是「結構性錯誤」（例如你的 API 金鑰過期、欄位格式不對、第三方服務掛掉），重試再多次也沒用，這時候你需要知道出了什麼問題。

這就是 Error Workflow 存在的意義——它不是用來修復錯誤，而是用來「讓你知道錯誤發生了」並且「提供足夠資訊讓你快速修復」。

💡 Alex 的觀察

我自己在運維 雲端方程式 Cloud F1 社群 的 n8n 系統時，Error Workflow 是最早期就建立的基礎設施。我的觀察是：很多人低估了錯誤處理的重要性，總是想著「等工作流穩定了再說」，結果就是永遠不穩定。

大家可以想想看，自動化的價值就在於「你不用一直盯著看」，但如果沒有監控機制，你要怎麼知道系統有沒有正常運作？你只有兩個選擇：一是每天手動去檢查結果（那就失去自動化的意義了），二是等到使用者或客戶來反應「欸怎麼沒收到東西」（那就太晚了）。

我建議的做法是：Error Workflow 要在第一個正式上線的工作流之前就建好。 就像核電廠一樣，你不會等電廠蓋好了才開始規劃緊急應變計畫對吧？引擎蓋底下的基礎設施先打好，你的民生設施就會 OK。

其實我是覺得，n8n 的 Error Workflow 設計算是中規中矩——它確實不太行的地方是「錯誤資訊的可讀性」。原始的錯誤訊息常常是一堆技術性的 stack trace（堆疊追蹤），對一般人來講影響不大，因為你只需要知道「哪個工作流」、「哪個節點」、「什麼時候」掛掉就夠了，不用看懂整個錯誤細節。

但是對一般人來講影響不大——因為重點不是看懂錯誤訊息的每一行，而是「有通知」、「有記錄」、「能追蹤」這三個核心功能。這三個做好，99% 的問題都能快速定位。

🔧 如何設定 n8n 錯誤處理工作流

好，再來就是重點了。我們直接來介紹完整的錯誤處理工作流設計，基本上有五個步驟：

核心流程架構

工作流錯誤 → Error Trigger → 收集錯誤資訊 → 三大通知方式 → 日誌記錄 → 統計分析

步驟一：建立 Error Workflow

  1. 在 n8n 中建立一個新的工作流，命名為「Error Workflow - 全域錯誤處理」
  2. 加入 Error Trigger 節點（這是錯誤處理的起點）
  3. Error Trigger 會自動接收來自其他工作流的錯誤事件

Error Trigger 節點會提供以下錯誤資訊：

{
  "execution": {
    "id": "12345",
    "workflowId": "workflow-abc",
    "workflowName": "LINE 訊息自動回覆",
    "mode": "trigger",
    "startedAt": "2026-02-11T10:30:00.000Z",
    "stoppedAt": "2026-02-11T10:30:15.000Z",
    "finished": false,
    "status": "error"
  },
  "workflow": {
    "id": "workflow-abc",
    "name": "LINE 訊息自動回覆",
    "active": true
  },
  "error": {
    "message": "API key is invalid",
    "timestamp": "2026-02-11T10:30:15.000Z",
    "node": "LINE Notify",
    "description": "Authentication failed"
  }
}

步驟二：收集與格式化錯誤資訊

用 Code 節點來整理錯誤資訊，讓通知更易讀：

// n8n Code 節點 — 格式化錯誤訊息
const execution = $input.item.json.execution;
const workflow = $input.item.json.workflow;
const error = $input.item.json.error;

// 提取關鍵資訊
const workflowName = workflow.name || '未命名工作流';
const errorNode = error.node || '未知節點';
const errorMessage = error.message || '無錯誤訊息';
const errorTime = new Date(error.timestamp).toLocaleString('zh-TW', {
  timeZone: 'Asia/Taipei',
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  second: '2-digit'
});

// 計算執行時長
const startTime = new Date(execution.startedAt);
const stopTime = new Date(execution.stoppedAt);
const duration = Math.round((stopTime - startTime) / 1000); // 秒

// 錯誤等級判斷（可自訂邏輯）
let severity = 'MEDIUM';
if (errorMessage.includes('API key') || errorMessage.includes('Authentication')) {
  severity = 'HIGH';  // 認證錯誤 = 嚴重
} else if (errorMessage.includes('timeout')) {
  severity = 'LOW';   // 超時錯誤 = 輕微（可能只是網路問題）
}

// 回傳格式化資料
return {
  workflowName,
  errorNode,
  errorMessage,
  errorTime,
  duration,
  severity,
  executionId: execution.id,
  workflowId: workflow.id
};

步驟三：三大通知方法設計

接下來是重點——根據錯誤的嚴重程度，選擇適合的通知方式。我通常會用 Switch 節點來做分流：

通知方法 1: LINE Notify（即時推播）

適用場景：高嚴重性錯誤，需要立刻處理

節點：HTTP Request (LINE Notify API)
URL：https://notify-api.line.me/api/notify
Method：POST
Headers：
  Authorization: Bearer YOUR_LINE_NOTIFY_TOKEN
Body：
  message: |
    ⚠️ n8n 錯誤警報

    工作流：{{ $json.workflowName }}
    失敗節點：{{ $json.errorNode }}
    錯誤訊息：{{ $json.errorMessage }}
    發生時間：{{ $json.errorTime }}
    執行時長：{{ $json.duration }} 秒
    嚴重等級：{{ $json.severity }}

    執行 ID：{{ $json.executionId }}

LINE Notify 的好處是你走到哪裡都能收到通知，手機推播很即時。缺點是訊息比較短，無法附上完整的技術細節。

通知方法 2: Email（詳細報告）

適用場景：需要完整錯誤資訊的技術報告

節點：Send Email (Gmail)
收件人：your-email@gmail.com
主題：[n8n Error] {{ $json.workflowName }} 執行失敗
內容：（HTML 格式）
<!DOCTYPE html>
<html>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
  <div style="background: #f44336; color: white; padding: 20px; border-radius: 5px;">
    <h2>⚠️ n8n 工作流執行失敗</h2>
  </div>

  <div style="padding: 20px; background: #f9f9f9; margin: 20px 0; border-radius: 5px;">
    <h3>錯誤摘要</h3>
    <table style="width: 100%; border-collapse: collapse;">
      <tr>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;"><strong>工作流名稱</strong></td>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;">{{ $json.workflowName }}</td>
      </tr>
      <tr>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;"><strong>失敗節點</strong></td>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;">{{ $json.errorNode }}</td>
      </tr>
      <tr>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;"><strong>錯誤訊息</strong></td>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;">{{ $json.errorMessage }}</td>
      </tr>
      <tr>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;"><strong>發生時間</strong></td>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;">{{ $json.errorTime }}</td>
      </tr>
      <tr>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;"><strong>執行時長</strong></td>
        <td style="padding: 8px; border-bottom: 1px solid #ddd;">{{ $json.duration }} 秒</td>
      </tr>
      <tr>
        <td style="padding: 8px;"><strong>嚴重等級</strong></td>
        <td style="padding: 8px;">{{ $json.severity }}</td>
      </tr>
    </table>
  </div>

  <div style="padding: 20px; background: #fff; border: 1px solid #ddd; border-radius: 5px;">
    <h3>快速操作</h3>
    <p>
      <a href="https://your-n8n-instance.com/workflow/{{ $json.workflowId }}"
         style="background: #2196F3; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; display: inline-block;">
        查看工作流
      </a>
      <a href="https://your-n8n-instance.com/execution/{{ $json.executionId }}"
         style="background: #4CAF50; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; display: inline-block; margin-left: 10px;">
        查看執行記錄
      </a>
    </p>
  </div>
</body>
</html>

Email 的優勢是可以放很多資訊，而且方便存檔、轉發給團隊成員。

通知方法 3: Google Sheet（日誌記錄）

適用場景：長期追蹤、趨勢分析、報表產出

  1. 建立一個 Google Sheet，命名為「n8n 錯誤日誌」
  2. 欄位設定：
欄位說明
A: Timestamp錯誤發生時間
B: Workflow Name工作流名稱
C: Error Node失敗節點
D: Error Message錯誤訊息
E: Severity嚴重等級
F: Duration (s)執行時長
G: Execution ID執行 ID
H: Status處理狀態（待處理/已修復）
  1. 用 Google Sheets 節點的「Append Row」操作，自動新增錯誤記錄

這邊要特別注意，Google Sheets 有寫入速率限制（每 100 秒 100 次寫入）。如果你的工作流錯誤很頻繁，建議加上 Aggregate 節點，每 5 分鐘批次寫入一次，避免超過限制。

步驟四：設定工作流使用 Error Workflow

建好 Error Workflow 之後，你需要在每個正式工作流裡指定它：

  1. 打開你要監控的工作流（例如「LINE 訊息自動回覆」）
  2. 點擊畫面右上角的 Settings 按鈕
  3. 找到「Error Workflow」選項
  4. 選擇你剛建立的「Error Workflow - 全域錯誤處理」
  5. 儲存設定

這樣一來，這個工作流只要發生任何錯誤，都會自動觸發 Error Workflow。

📊 三大通知方法比較分析

如果你在猶豫要用哪種通知方式，這邊整理了一個比較表：

比較項目LINE NotifyEmailGoogle Sheet
即時性極高（秒級推播）高（分鐘級）低（批次記錄）
資訊完整度低（簡短摘要）高（完整 HTML）極高（結構化資料）
適用場景緊急錯誤、需立刻處理詳細報告、團隊共享長期追蹤、趨勢分析
設定難度簡單（一個 API Token）中等（需 Gmail 授權）簡單（OAuth 授權）
查詢便利性低（訊息會被刷掉）中（Email 搜尋）高（可篩選、排序）
成本免費免費（Gmail 限額）免費
通知限制1,000 則/小時500 封/天（Gmail）100 次/100 秒寫入
歷史記錄無（LINE 群組有限）有（Email 信箱）有（永久保存）
團隊協作中（可建 LINE 群組）高（可 CC 多人）極高（共用試算表）

我的建議是：三種都用，根據嚴重程度分流。

  • HIGH 嚴重性：LINE + Email + Google Sheet（全開）
  • MEDIUM 嚴重性：Email + Google Sheet（不打擾手機）
  • LOW 嚴重性：Google Sheet only（只記錄不通知）

這樣你就不會被通知轟炸，但又能確保重要問題不會漏掉。

🔄 進階設定：避免通知轟炸

如果你的工作流每分鐘觸發一次，一旦出錯就會每分鐘發一次通知，你的手機會被炸掉。這邊分享幾個策略：

策略 1: 冷卻時間（Cooldown）

在 Error Workflow 裡加一個檢查機制，如果同一個工作流在 5 分鐘內已經發過通知，就跳過：

// n8n Code 節點 — 冷卻時間檢查
const workflowId = $json.workflowId;
const currentTime = Date.now();

// 從 n8n 的 Static Data（工作流變數）讀取上次通知時間
const lastNotifyTime = $workflow.staticData[`lastNotify_${workflowId}`] || 0;
const cooldownMinutes = 5;
const cooldownMs = cooldownMinutes * 60 * 1000;

// 檢查是否在冷卻期內
if (currentTime - lastNotifyTime < cooldownMs) {
  // 在冷卻期內，跳過通知
  return { skip: true };
} else {
  // 超過冷卻期，記錄時間並發送通知
  $workflow.staticData[`lastNotify_${workflowId}`] = currentTime;
  return { skip: false, ...($json) };
}

然後用 IF 節點，如果 skip === true 就只記錄到 Google Sheet，不發 LINE 或 Email。

策略 2: 錯誤計數與合併通知

如果錯誤很頻繁，可以改成「每小時統計一次，用一封 Email 報告所有錯誤」：

  1. 所有錯誤先只記錄到 Google Sheet
  2. 用 Schedule Trigger 每小時跑一次
  3. 讀取 Google Sheet 中過去一小時的錯誤記錄
  4. 用 Code 節點彙整成報表格式
  5. 用 Email 發送「每小時錯誤摘要」

這個方法適合錯誤量大、但不是每個都急迫的情境。

✅ 重點整理

  1. Error Workflow 是 n8n 自動化的基礎設施，不是「等穩定了再加」，而是「第一個工作流上線前就要有」
  2. 三大通知方法各有適用場景：LINE 即時推播、Email 詳細報告、Google Sheet 長期追蹤
  3. 錯誤分級很重要：HIGH/MEDIUM/LOW 三個等級，不同等級不同通知策略，避免通知轟炸
  4. 冷卻時間機制能防止同一個錯誤短時間內重複通知，用 $workflow.staticData 記憶上次通知時間
  5. Google Sheets 日誌是趨勢分析的關鍵，可以看出哪些工作流最常出錯、什麼時間容易出問題
  6. Error Trigger 提供完整錯誤資訊，包括工作流名稱、失敗節點、錯誤訊息、執行時間、執行 ID
  7. 每個工作流都要在 Settings 指定 Error Workflow，不然錯誤不會被捕捉到

不用一次學完，慢慢來比較快。先把基本的「Error Trigger → LINE 通知」做起來，確認能收到通知後，再加上 Google Sheet 記錄和冷卻時間機制。

❓ FAQ

Q1: Error Workflow 跟節點內建的「Retry on Fail」有什麼差別？

「Retry on Fail」（重試機制）是針對單一節點設定的，當該節點失敗時會自動重試 N 次。這個功能適合處理暫時性錯誤（例如 API 暫時無回應、網路不穩）。Error Workflow 則是針對整個工作流的錯誤處理——當重試也失敗、或是根本無法重試的錯誤（例如認證失敗、欄位格式錯誤）發生時，Error Workflow 會被觸發。簡單來說，Retry 是「自動修復」，Error Workflow 是「通知你來修復」。

Q2: 如何設定只有特定工作流使用 Error Workflow？

每個工作流的 Error Workflow 是獨立設定的。你可以建立多個 Error Workflow（例如「高優先級錯誤處理」和「低優先級錯誤處理」），然後在不同工作流的 Settings 裡指定不同的 Error Workflow。如果某個工作流你不想監控（例如測試用的工作流），就直接不設定 Error Workflow 即可。

Q3: Error Workflow 本身如果出錯怎麼辦？

這是個好問題——如果負責處理錯誤的工作流自己掛掉，那就沒人知道錯誤了。n8n 的設計是：Error Workflow 本身的錯誤不會再觸發另一個 Error Workflow（避免無限遞迴）。我的建議是讓 Error Workflow 盡可能簡單——不要在裡面做複雜的邏輯、不要呼叫太多外部 API。如果真的擔心，可以在 Error Workflow 裡加上「最後防線」：用 n8n 的 Execute Workflow 節點呼叫另一個超簡化版的通知工作流（只有 Webhook + LINE Notify），確保至少有一條通知路徑是穩定的。

Q4: 可以從 Error Workflow 自動修復錯誤並重新執行工作流嗎?

理論上可以，但我不建議。你可以在 Error Workflow 裡用 HTTP Request 節點呼叫 n8n 的 API，觸發原工作流重新執行。但問題是：如果錯誤不是暫時性的（例如 API 金鑰真的過期了），重新執行也只會再失敗一次，然後又觸發 Error Workflow，形成無限迴圈。更安全的做法是：在 Error Workflow 裡記錄錯誤，然後由人工判斷是否需要修復並手動重新執行。如果你真的需要自動恢復，建議在原工作流裡用「Retry on Fail」機制，而不是在 Error Workflow 層級做。

Q5: Google Sheets 錯誤日誌累積太多怎麼辦？

有幾個處理方式。最簡單的是定期手動歸檔——每個月建一個新的 Sheet 分頁，把舊資料搬過去。進階做法是用 n8n 的 Schedule Trigger 每周跑一次「日誌清理」工作流：讀取 Google Sheet 中超過 30 天的錯誤記錄，匯出成 CSV 備份到 Google Drive 或 Dropbox，然後從原 Sheet 刪除。更進階的做法是改用真正的資料庫（PostgreSQL、MySQL）來儲存日誌，但對一般使用者來說，Google Sheets 的 100 萬行上限已經非常夠用（平均一天 100 個錯誤的話，可以用 27 年）。

Q6: 如何分析錯誤趨勢並找出問題根源？

這是 Google Sheets 日誌的真正價值所在。我建議在同一個 Google Sheet 裡建立一個「Dashboard」分頁，用 Google Sheets 的函數做統計：

// 最常出錯的工作流 TOP 5
=QUERY('錯誤日誌'!A:B, "SELECT B, COUNT(B) WHERE B IS NOT NULL GROUP BY B ORDER BY COUNT(B) DESC LIMIT 5")

// 最常失敗的節點 TOP 5
=QUERY('錯誤日誌'!A:C, "SELECT C, COUNT(C) WHERE C IS NOT NULL GROUP BY C ORDER BY COUNT(C) DESC LIMIT 5")

// 每日錯誤趨勢（用 COUNTIF 統計每天的錯誤數）
=COUNTIFS('錯誤日誌'!A:A, ">="&TODAY()-7, '錯誤日誌'!A:A, "<"&TODAY()-6)

你也可以用 Google Sheets 的圖表功能，把每日錯誤數做成折線圖。如果你發現某個工作流的錯誤數突然飆升，可能就是該工作流的設計有問題、或是它依賴的第三方服務不穩定。

🎯 下一步行動

🎓 想更有系統地學會這些技巧？ 到 AI 職場工作術（雲端方程式 Cloud F1 旗艦課程） 看看完整的實作路徑。

如果你看到這邊，我建議你現在就打開 n8n，花 10 分鐘先把最基本的版本做出來：一個 Error Trigger + 一個 LINE Notify 節點。先不用管 Google Sheet、不用管冷卻時間，先確認錯誤能被捕捉到、通知能送到手機。等這個基礎穩了，再一個一個加上去。

每個高手都是從新手開始的，重點是先動手。第一次沒做好或是聽不懂，代表你是正常人！先求大概懂，再開始用，最後才能做成功。

想看完整的操作示範，我在 YouTube 影片裡有 step-by-step 的畫面教學：

🔗 相關資源

本文改編自 YouTube 影片 EP18，由 Alex Hsieh 撰寫。最後更新：2026-02-11

想把這篇學到的用進日常工作？

「AI 職場工作術」課程把這類實戰經驗整理成一步步的教學，帶你系統化練出跟 AI 協作的產能。

看 AI 職場工作術課程 →

本文作者：Alex Hsieh，SRE / DevOps 背景出身，現為企業 AI 導入顧問，也是「AI 相談室」課程講師。專注把 AI 自動化真正落地到企業日常流程，而不是停留在 Demo。

目錄
  1. 專業導讀
  2. 你將學到
  3. 🎯 什麼是 n8n 錯誤處理工作流？
  4. 💡 Alex 的觀察
  5. 🔧 如何設定 n8n 錯誤處理工作流
  6. 核心流程架構
  7. 步驟一：建立 Error Workflow
  8. 步驟二：收集與格式化錯誤資訊
  9. 步驟三：三大通知方法設計
  10. 步驟四：設定工作流使用 Error Workflow
  11. 📊 三大通知方法比較分析
  12. 🔄 進階設定：避免通知轟炸
  13. 策略 1: 冷卻時間（Cooldown）
  14. 策略 2: 錯誤計數與合併通知
  15. ✅ 重點整理
  16. ❓ FAQ
  17. Q1: Error Workflow 跟節點內建的「Retry on Fail」有什麼差別？
  18. Q2: 如何設定只有特定工作流使用 Error Workflow？
  19. Q3: Error Workflow 本身如果出錯怎麼辦？
  20. Q4: 可以從 Error Workflow 自動修復錯誤並重新執行工作流嗎?
  21. Q5: Google Sheets 錯誤日誌累積太多怎麼辦？
  22. Q6: 如何分析錯誤趨勢並找出問題根源？
  23. 🎯 下一步行動
  24. 🔗 相關資源

相關文章