n8n 錯誤處理工作流｜3 大通知方法即時監控

Q: Q1: Error Workflow 會不會影響主工作流的執行速度？

**A**: 不會。Error Workflow 是在主工作流執行失敗後才觸發，而且是異步執行，不會影響主工作流的效能。 實測數據： - **沒有 Error Workflow** — 工作流失敗後就直接結束 - **有 Error Workflow** — 工作流失敗後，Error Workflow 會在背景執行（通常 1-3 秒），但主工作流已經結束了 所以你完全不用擔心效能問題，可以放心設定 Error Workflow。 ---

Q: Q2: 如果 Error Workflow 本身也失敗了怎麼辦？

**A**: 這是個好問題！確實有可能發生（例如 LINE Notify Token 過期、Google Sheet 權限不足等）。 我的建議是： 1. **Error Workflow 要盡量簡化** — 不要在 Error Workflow 裡面做太複雜的邏輯，降低失敗機率 2. **設定外部監控** — 用 UptimeRobot 或 Better Uptime 監控 n8n 本身是否正常運作 3. **定期檢查 Google Sheet** — 如果某天突然沒有新的錯誤記錄，可能代表 Error Workflow 本身出問題了 另外，n8n 的執行記錄（Executions）裡面也會保留 Error Workflow 的執行歷史，可以從那邊檢查 Error Workflow 是否正常運作。 ---

Q: Q3: 可以針對特定類型的錯誤，執行不同的處理邏輯嗎？

**A**: 可以！我在 Step 2 的 Function 節點示範了基本的錯誤分級，你可以擴展成更複雜的邏輯。 **進階範例：針對不同錯誤類型執行不同動作** ```javascript // 在 Error Workflow 的 Function 節點加入以下邏輯 const errorMessage = $input.item.json.error.message; const workflowName = $input.item.json.workflow.name; // 判斷錯誤類型 let errorType = 'unknown'; let action = 'notify'; // API Rate Limit 錯誤 → 自動重試 if (errorMessage.includes('rate limit') || errorMessage.includes('429')) { errorType = 'rate_limit'; action = 'retry'; } // 資料庫連線錯誤 → 立即警報 + 通知 DevOps else if (errorMessage.includes('database') || errorMessage.includes('connection')) { errorType = 'database'; action = 'critical_alert'; } // API 認證錯誤 → 通知相關負責人 else if (errorMessage.includes('unauthorized') || errorMessage.includes('401')) { errorType = 'auth_error'; action = 'notify_owner'; } // 使用者輸入錯誤 → 只記錄不通知 else if (errorMessage.includes('validation') || errorMessage.includes('invalid input')) { errorType = 'user_input'; action = 'log_only'; } return { ...originalData, errorType, action, }; ``` 然後用 Switch 節點根據 `action` 來決定要執行哪些通知節點。 ---

Q: Q4: LINE 通知太多怎麼辦？如何設定通知冷卻？

**A**: 如果同一個工作流短時間內重複失敗，確實會造成通知轟炸。我的解決方案是加入「通知冷卻機制」。 **方法一：用 n8n 的 Sticky Note（簡單版）** 在 Error Workflow 加入一個 HTTP Request 節點，把上次通知時間存到你的資料庫或 Redis。然後在發送 LINE 通知前，先檢查距離上次通知是否超過 N 分鐘。 **方法二：用 Google Sheet 記錄（無需額外服務）** ```javascript // 在發送 LINE 通知前，加入這個 Function 節點 const workflowId = $json.workflowId; const errorMessage = $json.errorMessage; // 生成錯誤的唯一識別（工作流 ID + 錯誤訊息的前 100 字） const errorHash = `${workflowId}_${errorMessage.substring(0, 100)}`; // 從上一個節點（Google Sheet Lookup）取得上次通知時間 const lastNotifyTime = $('Google Sheet Lookup').first().json.lastNotifyTime; const cooldownMinutes = 30; // 冷卻時間 30 分鐘 const now = new Date(); const shouldNotify = !lastNotifyTime || (now - new Date(lastNotifyTime)) > cooldownMinutes * 60 * 1000; return { ...originalData, shouldNotify, errorHash, }; ``` 然後用 IF 節點檢查 `shouldNotify`，如果是 true 才發送 LINE 通知。 我的建議冷卻時間： - **Critical 錯誤** — 30 分鐘（避免短時間內重複通知，但不能太久） - **Warning 錯誤** — 2 小時（不緊急，可以延長冷卻時間） - **Info 錯誤** — 不通知，只記錄 ---

Q: Q5: Error Workflow 可以自動修復錯誤嗎？

**A**: 可以，但要看錯誤類型。有些錯誤是可以自動修復的，有些則不行。 **可以自動修復的錯誤類型**： 1. **API Rate Limit** — 等待一段時間後重試 2. **暫時性網路問題** — 立即或延遲重試 3. **資料格式錯誤** — 自動調整格式後重新處理（例如移除多餘空格） **不建議自動修復的錯誤類型**： 1. **資料庫錯誤** — 可能需要人工檢查 2. **商業邏輯錯誤** — 自動修復可能造成資料錯誤 3. **認證失敗** — 需要更新 Token 或密碼 **自動重試的實作方式**： 在 Error Workflow 加入以下邏輯： ```javascript // Function 節點：判斷是否可以重試 const errorMessage = $json.errorMessage; const executionMode = $json.executionMode; const retryCount = $json.retryCount || 0; const maxRetries = 3; // 只有特定錯誤類型才重試 const retryableErrors = [ 'rate limit', 'timeout', 'ECONNREFUSED', 'ETIMEDOUT', ]; const shouldRetry = retryableErrors.some(keyword => errorMessage.toLowerCase().includes(keyword) ) && retryCount < maxRetries && executionMode !== 'manual'; return { ...originalData, shouldRetry, retryCount: retryCount + 1, }; ``` 然後用 IF 節點判斷 `shouldRetry`，如果是 true 就用 HTTP Request 節點呼叫主工作流的 Webhook 觸發重新執行。 **這邊要特別注意**：自動重試要小心設計，避免造成無窮迴圈或資料重複。我的建議是： - 設定最大重試次數（例如 3 次） - 加入延遲機制（例如第一次等 1 分鐘、第二次等 5 分鐘、第三次等 15 分鐘） - 最終失敗後還是要發通知給人工處理 ---

Q: Q6: 如何分析 Google Sheet 的錯誤趨勢？

**A**: Google Sheet 累積一段時間後，就可以用來做錯誤趨勢分析。我會在 Google Sheet 加入第二個工作表「統計儀表板」，用函數自動產生報表。 **實用的統計維度**： 1. **每日錯誤次數趨勢** ``` =COUNTIF('Error Log'!A:A, "2025-04-30") ``` 2. **各工作流的錯誤率排名** ``` =QUERY('Error Log'!A:H, "SELECT C, COUNT(C) WHERE C != '' GROUP BY C ORDER BY COUNT(C) DESC") ``` 3. **最常見的錯誤訊息** ``` =QUERY('Error Log'!A:H, "SELECT F, COUNT(F) WHERE F != '' GROUP BY F ORDER BY COUNT(F) DESC LIMIT 10") ``` 4. **Critical 錯誤佔比** ``` =COUNTIF('Error Log'!B:B, "Critical") / COUNTA('Error Log'!B:B) ``` 5. **執行模式分布**（manual vs trigger vs webhook） ``` =QUERY('Error Log'!A:H, "SELECT H, COUNT(H) GROUP BY H") ``` 這些統計數據可以幫助你： - **找出最不穩定的工作流** — 優先優化錯誤率最高的工作流 - **識別系統性問題** — 如果某類錯誤突然增加，可能是外部 API 變更或 n8n 版本升級造成的 - **評估改進成效** — 優化後錯誤率是否真的降低了 我建議每個月看一次統計儀表板，把錯誤率高的工作流列入優化清單。 ---

2025年4月30日 · 約 12 分鐘閱讀 · Alex Hsieh

更新於 2026年2月11日

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

專業導讀

來了！馬上來介紹我們 n8n 錯誤處理的工作流。你有沒有遇過這種情況？n8n 工作流執行失敗了，但你完全不知道，直到客戶或同事來問「為什麼訂單沒進系統」、「為什麼報表沒自動產出」，你才發現自動化早就掛了好幾天？

今天我要跟大家分享一個超級實用的功能：n8n Error Workflow 錯誤處理工作流。我在影片裡面示範了利用工作流來觸發錯誤，只要發生錯誤，我們就傳送訊息到三個地方 — 分別是郵件、試算表跟我們的 LINE。一句話說明就是：出事的時候自動通知我，叫救護車來幫忙，Call 911。

我在協助 500+ 學員建立自動化工作流的過程中，發現「錯誤監控」是最容易被忽略、卻也是最重要的一環。很多人花了好幾天做出複雜的工作流，卻沒有設定錯誤處理，結果工作流掛了一個月才發現。

這篇文章我會用最實際的方式，手把手教你建立三種錯誤通知機制（LINE、Email、Google Sheet），讓你的 n8n 自動化系統從「可能會壞但不知道」，升級成「壞了立刻知道、而且有完整記錄可以追查」的專業級系統。

你將學到

✅ n8n Error Workflow 完整設定流程 — 從建立到關聯主工作流的完整步驟
✅ 三大錯誤通知方法 — LINE 即時推播、Email 詳細報告、Google Sheet 歷史記錄
✅ Error Trigger 節點深度解析 — 如何取得錯誤訊息、堆疊追蹤、執行 ID 等關鍵資訊
✅ 實際案例示範 — 用真實的錯誤情境測試驗證
✅ 進階技巧 — 錯誤分級、通知冷卻、自動重試機制
✅ 常見錯誤排查指南 — 快速定位問題根源的實用技巧

🎯 什麼是 n8n Error Workflow？

n8n Error Workflow（錯誤處理工作流）是 n8n 的內建功能，當你的任何一個工作流執行失敗時，會自動觸發指定的 Error Workflow，讓你可以在裡面定義錯誤發生時要執行的動作（例如發送通知、記錄錯誤、嘗試重試等）。簡單來說就是：出事的時候自動通知我，叫救護車來幫忙，Call 911。

我在影片裡用了一張圖來說明，基本上會有兩種主要的錯誤：

第一種是節點層級的錯誤（Node Level），就是你的某一個節點出問題了。這種錯誤有三種處理方式：

停止工作流 — 發生錯誤馬上停止，整個流程不再往下跑
繼續執行 — 節點有錯誤的時候忽略它繼續做
使用錯誤輸出繼續 — 把這個錯誤的東西打到另外一個點上，讓那個點去做後續錯誤的處理

第二種是工作流程層級的錯誤（Workflow Level），這才是我們今天的主角。每一個工作流程會指定一個錯誤處理工作流，我錯了我就 Call 911、Call 救護車。當主要的工作流程發現未知的錯誤，就觸發這個錯誤機制，我們在這裡建議用三種方式通知你：傳 LINE、傳 Mail、傳到試算表。

大家可以想像一下，如果你的 n8n 裡面有 10 個工作流在跑，沒有 Error Workflow 的話，你就要每天手動去檢查每個工作流的執行記錄，看有沒有紅色的錯誤圖示。但有了 Error Workflow，只要任何一個工作流掛了，你的手機立刻跳出 LINE 通知，這個效率差距有多大？

💡 Alex 的實戰觀察

我從 2023 年開始用 n8n 做各種自動化專案，從個人的內容生產流程到企業的訂單處理系統，累積了超過 100 個工作流的運營經驗。我的觀察是，沒有設定 Error Workflow 的工作流，平均會有 30% 的執行失敗是延遲 24 小時以上才被發現的。

為什麼錯誤處理這麼重要，卻這麼容易被忽略？

開發時期的盲點 — 開發階段大家都專注在「功能做出來」，覺得錯誤處理可以之後再說
測試環境的假象 — 測試時工作流都正常執行，讓人以為上線後也會很穩定
心理上的抗拒 — 沒有人想承認自己的工作流會壞掉，所以不想花時間做錯誤處理

但現實是，就算你的工作流寫得再完美，外部 API 會掛、網路會斷、資料格式會變。這些都不是你能控制的，所以錯誤處理不是「可有可無」，而是「必須要有」。

三種錯誤通知方法的使用時機

我在影片裡面也特別說明了，三種通報方式大同小異，但每一種情境適合的不一樣，你也可以分開設計。我來幫大家整理一下：

通知方法	適用情境	特色	缺點
LINE 即時推播	金流、API 異常、網站上下線	快速即時收到通知	噪音比較多，會一直傳訊來
Email 詳細報告	每天/每小時的批次處理、非核心系統錯誤	易於整理，可用郵件規則過濾	反應速度較慢，有些人不看郵件
Google Sheet 記錄	需要系統性分析或歸檔的	可累積資料有報表，品質改善用	不即時，需搭配其他通知方式

影片裡我也給了一個快速選擇指南：如果你希望馬上知道錯誤，用 LINE；如果你要有個紀錄但不用馬上回應，用 Email；如果需要長期的統計跟分析錯誤，用 Google Sheet。就這麼簡單。

老實說，我自己喜歡用 Google Sheet 紀錄搭配 Email 來通知我。其實我個人比較不喜歡即時通知，因為對我來說，我在 n8n 放的都是不用馬上就要處理的事情。你可以根據自己的工作流重要性來選擇適合的組合。

老實說，Error Workflow 也有局限性

無法處理 n8n 本身掛掉 — 如果整個 n8n 服務掛了，Error Workflow 也無法執行。這時候你需要外部監控（例如 UptimeRobot）
通知風暴問題 — 如果設定不當，一個錯誤可能觸發大量通知，反而造成困擾
不是所有錯誤都該通知 — 有些錯誤是預期內的（例如使用者輸入錯誤格式），這種就不該發通知

所以我的建議是：Error Workflow 要搭配錯誤分級機制。我會把錯誤分成三級：

Critical（關鍵） — 立刻發 LINE + Email，例如金流異常、資料遺失
Warning（警告） — 只發 Email，例如 API Rate Limit、資料格式不符
Info（資訊） — 只記錄到 Google Sheet，例如使用者取消操作、重試成功

這邊要特別注意，錯誤分級的邏輯要寫在 Error Workflow 裡面，根據錯誤類型和來源工作流來判斷要用哪種通知方式。我會在 Step-by-Step 章節示範怎麼做。

🔧 Step-by-Step 完整設定教學

接下來我們馬上來講一下完整的 Error Workflow 建立流程。我會分成四個階段，每個階段都給你實際的操作步驟和程式碼範例。

Step 1: 建立 Error Workflow 基礎架構

首先我們要建立一個專門用來處理錯誤的工作流。

實際操作步驟

新增工作流
- 進入 n8n 首頁，點選「Add Workflow」
- 命名為「Error Workflow - 全局錯誤處理」（建議用有意義的名稱，方便管理）
加入 Error Trigger 節點
- 搜尋並拖入「Error Trigger」節點 — 就是那個像一個蟲蟲的感覺的圖示，我在影片裡面也開玩笑說這個蟲蟲就會做觸發
- 這個節點會在任何工作流發生錯誤時自動觸發
- 節點會提供以下資訊：
  - error.message — 錯誤訊息
  - error.stack — 堆疊追蹤（debug 用）
  - workflow.id — 發生錯誤的工作流 ID
  - workflow.name — 發生錯誤的工作流名稱
  - execution.id — 執行 ID（可以連結回 n8n 查看詳細記錄）
  - execution.mode — 執行模式（manual/trigger/webhook）
加入 Function 節點（錯誤資訊整理）
- 在 Error Trigger 後面加入「Code」節點
- 把錯誤資訊整理成易讀的格式：

// 從 Error Trigger 取得錯誤資訊
const errorMessage = $input.item.json.error.message;
const errorStack = $input.item.json.error.stack;
const workflowName = $input.item.json.workflow.name;
const workflowId = $input.item.json.workflow.id;
const executionId = $input.item.json.execution.id;
const executionMode = $input.item.json.execution.mode;

// 建立 n8n 執行記錄連結（方便點擊查看）
const executionUrl = `${$execution.baseUrl}/workflow/${workflowId}/executions/${executionId}`;

// 截取錯誤訊息前 500 字（避免太長）
const errorPreview = errorMessage.substring(0, 500);

// 判斷錯誤等級（這邊用簡單的關鍵字判斷，你可以根據需求調整）
let errorLevel = 'Warning';
const criticalKeywords = ['payment', 'database', 'critical', '金流', '資料庫', '訂單'];
const infoKeywords = ['cancelled', '取消', 'skipped', '跳過'];

if (criticalKeywords.some(keyword => errorMessage.toLowerCase().includes(keyword))) {
  errorLevel = 'Critical';
} else if (infoKeywords.some(keyword => errorMessage.toLowerCase().includes(keyword))) {
  errorLevel = 'Info';
}

// 格式化時間（台灣時區）
const errorTime = new Date().toLocaleString('zh-TW', { timeZone: 'Asia/Taipei' });

// 回傳整理後的錯誤資訊
return {
  errorLevel,
  errorTime,
  workflowName,
  workflowId,
  executionId,
  executionUrl,
  errorMessage: errorPreview,
  errorStack,
  executionMode,
  // 建立友善的錯誤摘要
  errorSummary: `[${errorLevel}] ${workflowName} 執行失敗\n時間：${errorTime}\n錯誤：${errorPreview}`,
};

這個節點的作用是把 Error Trigger 提供的原始資料，整理成後續通知節點可以直接使用的格式。

加入 Switch 節點（錯誤分流）
- 根據 errorLevel 來決定要用哪種通知方式
- 設定三個分支：
  - Route 1: Critical — {{ $json.errorLevel === 'Critical' }}
  - Route 2: Warning — {{ $json.errorLevel === 'Warning' }}
  - Route 3: Info — {{ $json.errorLevel === 'Info' }}

接下來我們分別在三個分支加入不同的通知方式。

Step 2: 設定 LINE 即時通知（Critical 錯誤）

Critical 等級的錯誤，我們要立刻發 LINE 通知，讓你能第一時間知道並處理。如果你不知道怎麼設定 LINE 的官方帳號去做推播、把錯誤訊息傳過去的話，可以參考我另一篇文章：8 分鐘學會 n8n 串接 LINE Messenger API。

實際操作步驟

準備 LINE Notify Token
- 進入 LINE Notify
- 登入後點選「個人頁面」→「發行權杖」
- 選擇要接收通知的聊天室（可以是個人或群組）
- 複製產生的 Token（只會顯示一次，記得儲存）
在 Critical 分支加入 HTTP Request 節點
- 節點名稱改為「發送 LINE 通知」
- 設定如下：

Method: POST
URL: https://notify-api.line.me/api/notify
Authentication: Generic Credential Type
  - Credential Type: Header Auth
  - Name: Authorization
  - Value: Bearer YOUR_LINE_NOTIFY_TOKEN

Body:
  Content-Type: application/x-www-form-urlencoded

  message: {{ $json.errorSummary }}

完整查看：{{ $json.executionUrl }}

測試 LINE 通知
- 先儲存 Error Workflow
- 建立一個測試用的工作流，故意讓它發生錯誤（例如用 HTTP Request 節點連到不存在的網址）
- 執行測試工作流，檢查 LINE 是否收到通知

LINE 通知內容範例：

[Critical] 訂單處理工作流 執行失敗
時間：2025-04-30 14:23:15
錯誤：Database connection timeout after 30s

完整查看：https://你的n8n網址/workflow/123/executions/456

這邊要特別注意，LINE Notify 有流量限制：

每小時最多 1000 則訊息
超過會被暫時封鎖

所以我建議加入「通知冷卻機制」，避免同一個錯誤短時間內重複通知。可以用 Redis 或 n8n 的 Sticky Note 來記錄上次通知時間。

Step 3: 設定 Email 詳細報告（Warning 錯誤）

Warning 等級的錯誤，我們用 Email 發送包含完整錯誤訊息和堆疊追蹤的詳細報告。

實際操作步驟

在 Warning 分支加入 Send Email 節點
- 如果你的 n8n 有設定 SMTP，可以用內建的「Send Email」節點
- 如果沒有，可以用 Gmail 的「Gmail」節點（需要設定 OAuth2 認證）
設定 Email 內容（使用 HTML 格式）

<!DOCTYPE html>
<html>
<head>
  <style>
    body { font-family: Arial, sans-serif; line-height: 1.6; }
    .header { background-color: #ff9800; color: white; padding: 20px; }
    .content { padding: 20px; }
    .error-box { background-color: #fff3e0; border-left: 4px solid #ff9800; padding: 15px; margin: 20px 0; }
    .stack-trace { background-color: #f5f5f5; padding: 15px; overflow-x: auto; font-family: monospace; font-size: 12px; }
    .button { background-color: #2196F3; color: white; padding: 10px 20px; text-decoration: none; display: inline-block; margin: 10px 0; }
  </style>
</head>
<body>
  <div class="header">
    <h2>⚠️ n8n 工作流警告通知</h2>
  </div>

  <div class="content">
    <h3>錯誤摘要</h3>
    <div class="error-box">
      <strong>工作流名稱：</strong> {{ $json.workflowName }}<br>
      <strong>發生時間：</strong> {{ $json.errorTime }}<br>
      <strong>執行模式：</strong> {{ $json.executionMode }}<br>
      <strong>錯誤等級：</strong> {{ $json.errorLevel }}
    </div>

    <h3>錯誤訊息</h3>
    <div class="error-box">
      {{ $json.errorMessage }}
    </div>

    <h3>堆疊追蹤 (Stack Trace)</h3>
    <div class="stack-trace">
      {{ $json.errorStack }}
    </div>

    <a href="{{ $json.executionUrl }}" class="button">查看完整執行記錄</a>

    <hr>
    <p style="color: #666; font-size: 12px;">
      此郵件由 n8n Error Workflow 自動發送<br>
      如需協助，請聯繫技術團隊
    </p>
  </div>
</body>
</html>

設定 Email 主旨

[n8n Warning] {{ $json.workflowName }} 執行異常 - {{ $json.errorTime }}

設定收件人
- To: 你的 Email（或技術團隊的 Email）
- CC: 如果需要副本給其他人（例如專案經理）

這個 Email 的好處是，包含完整的錯誤訊息和堆疊追蹤，讓你可以快速定位問題根源，不用再登入 n8n 後台慢慢找。

Step 4: 設定 Google Sheet 歷史記錄（所有錯誤）

不管是哪種等級的錯誤，我們都要記錄到 Google Sheet，方便長期追蹤和產生報表。如果是老朋友都知道，我在很多影片裡都用 Google Sheet 來記錄，這次也是一樣的老招。

實際操作步驟

準備 Google Sheet
- 建立一個新的 Google Sheet，命名為「n8n Error Log」
- 第一列設定欄位標題： | 時間 | 等級 | 工作流名稱 | 工作流 ID | 執行 ID | 錯誤訊息 | 執行連結 | 執行模式 |
設定 Google Sheets OAuth2 認證
- 在 n8n 的 Credentials 頁面新增「Google Sheets OAuth2 API」
- 按照指示完成 OAuth2 授權
在所有分支的最後加入 Google Sheets 節點
- 操作選擇「Append」（新增列）
- 選擇你的 Google Sheet 和工作表
- 欄位對應設定：

時間: {{ $json.errorTime }}
等級: {{ $json.errorLevel }}
工作流名稱: {{ $json.workflowName }}
工作流 ID: {{ $json.workflowId }}
執行 ID: {{ $json.executionId }}
錯誤訊息: {{ $json.errorMessage }}
執行連結: {{ $json.executionUrl }}
執行模式: {{ $json.executionMode }}

進階：加入錯誤統計
- 你可以在 Google Sheet 加入另一個工作表「統計」
- 用 COUNTIF、SUMIF 等函數統計：
  - 每天的錯誤次數
  - 各工作流的錯誤率
  - 最常見的錯誤類型

這個 Google Sheet 就像是你的「錯誤資料庫」，累積一段時間後，你可以用它來：

找出最常出錯的工作流，優先優化
分析錯誤趨勢，預測可能的系統問題
產生月報表給管理階層

Step 5: 關聯主工作流到 Error Workflow

Error Workflow 建立完成後，最後一步是把它關聯到你的主工作流。

實際操作步驟

開啟要監控的主工作流
- 例如「訂單處理工作流」
進入工作流設定
- 點選畫布右上角的「…」選單
- 選擇「Settings」
設定 Error Workflow
- 找到「Error Workflow」選項
- 從下拉選單選擇「Error Workflow - 全局錯誤處理」
- 儲存設定
測試驗證

特別注意：我在影片裡面強調過，按這個 Test Workflow 是不會有用的！按了它不會理你。因為在 n8n 的設計裡面，Test Workflow 就是測試，它不會觸發錯誤的工作流。你必須要把工作流**啟動（Active）**以後，才會觸發 Error Workflow。

我在影片裡的測試方式是用一個 Schedule Trigger 每 30 秒驅動一次，然後用 HTTP Request 打一個完全不知道是什麼的 URL，什麼東西都收不到就錯誤，就觸發後面錯誤的流程。你可以用同樣的方式來測試：
- 建立一個測試工作流，加入 Schedule Trigger（每 30 秒）+ HTTP Request（打不存在的 URL）
- **啟動（Active）**測試工作流
- 確認：
  - LINE 有收到通知（如果是 Critical）
  - Email 有收到報告（如果是 Warning）
  - Google Sheet 有新增記錄
- 測試完記得把測試工作流 Inactive 掉

Pro Tip: 你可以建立多個 Error Workflow，針對不同類型的工作流使用不同的錯誤處理邏輯。例如：

Error Workflow - 金流專用 — Critical 錯誤要通知財務和技術
Error Workflow - 行銷專用 — Warning 錯誤只通知行銷團隊
Error Workflow - 測試專用 — 所有錯誤只記錄不通知

大家記得，先求大概懂，再開始用，最後才能做成功。第一次設定 Error Workflow 可能會覺得複雜，但設定好之後就是一勞永逸，可以套用到所有工作流。

📊 比較分析：三種錯誤通知方法

比較維度	LINE 即時推播	Email 詳細報告	Google Sheet 記錄
即時性	⭐⭐⭐⭐⭐ 秒收	⭐⭐⭐⭐ 1-2分鐘	⭐⭐⭐ 即時寫入
資訊完整度	⭐⭐ 只有摘要	⭐⭐⭐⭐⭐ 完整堆疊追蹤	⭐⭐⭐⭐ 結構化資料
長期追蹤	❌ 訊息會被洗掉	⚠️ 需要手動整理	✅ 完整歷史記錄
設定難度	⭐⭐⭐ 需要 LINE Notify	⭐⭐⭐⭐ 需要 SMTP/OAuth	⭐⭐⭐⭐ 需要 Google OAuth
適用情境	關鍵業務立即警報	需要深入分析的錯誤	所有錯誤長期追蹤
通知成本	免費（有流量限制）	免費（Gmail）或付費	免費（Google Sheet）
團隊協作	✅ 可加入群組	✅ 可 CC 多人	✅ 共用試算表
搜尋能力	❌ 難搜尋	⭐⭐⭐ Email 搜尋	⭐⭐⭐⭐⭐ 試算表篩選

我的推薦組合

工作流類型	推薦通知方式	理由
金流、訂單	LINE + Email + Sheet	關鍵業務，需要立即警報 + 完整記錄
內容生產	Email + Sheet	不需要立即處理，但要完整記錄
定時報表	Sheet only	錯誤可以隔天檢視，重點是追蹤趨勢
測試工作流	Sheet only	只需要記錄，不需要通知

✅ 重點整理

Error Workflow 是保全系統，不是奢侈品 — 就像核電廠的安全氣閘，監控系統打好了，自動化工作流才能穩定運作
三種通知方式各有適用情境 — LINE 即時警報、Email 深入分析、Google Sheet 長期追蹤，三者搭配使用才完整
錯誤分級機制很重要 — Critical、Warning、Info 三個等級，避免通知風暴，也避免重要錯誤被忽略
Error Trigger 提供完整的錯誤資訊 — 錯誤訊息、堆疊追蹤、工作流資訊、執行 ID 都有，要善用這些資訊來快速定位問題
一個 Error Workflow 可以服務多個主工作流 — 不用每個工作流都建一個 Error Workflow，集中管理更有效率
Google Sheet 是錯誤追蹤的最佳工具 — 結構化資料、容易搜尋、方便產生報表，累積幾個月後價值很高
測試驗證不能省 — 設定完一定要實際測試，確認 LINE、Email、Sheet 都有正常接收到通知
進階技巧：加入自動重試機制 — 有些錯誤是暫時性的（例如 API Rate Limit），可以在 Error Workflow 加入延遲重試邏輯

❓ 常見問題 FAQ

Q1: Error Workflow 會不會影響主工作流的執行速度？

A: 不會。Error Workflow 是在主工作流執行失敗後才觸發，而且是異步執行，不會影響主工作流的效能。

實測數據：

沒有 Error Workflow — 工作流失敗後就直接結束
有 Error Workflow — 工作流失敗後，Error Workflow 會在背景執行（通常 1-3 秒），但主工作流已經結束了

所以你完全不用擔心效能問題，可以放心設定 Error Workflow。

Q2: 如果 Error Workflow 本身也失敗了怎麼辦？

A: 這是個好問題！確實有可能發生（例如 LINE Notify Token 過期、Google Sheet 權限不足等）。

我的建議是：

Error Workflow 要盡量簡化 — 不要在 Error Workflow 裡面做太複雜的邏輯，降低失敗機率
設定外部監控 — 用 UptimeRobot 或 Better Uptime 監控 n8n 本身是否正常運作
定期檢查 Google Sheet — 如果某天突然沒有新的錯誤記錄，可能代表 Error Workflow 本身出問題了

另外，n8n 的執行記錄（Executions）裡面也會保留 Error Workflow 的執行歷史，可以從那邊檢查 Error Workflow 是否正常運作。

Q3: 可以針對特定類型的錯誤，執行不同的處理邏輯嗎？

A: 可以！我在 Step 2 的 Function 節點示範了基本的錯誤分級，你可以擴展成更複雜的邏輯。

進階範例：針對不同錯誤類型執行不同動作

// 在 Error Workflow 的 Function 節點加入以下邏輯

const errorMessage = $input.item.json.error.message;
const workflowName = $input.item.json.workflow.name;

// 判斷錯誤類型
let errorType = 'unknown';
let action = 'notify';

// API Rate Limit 錯誤 → 自動重試
if (errorMessage.includes('rate limit') || errorMessage.includes('429')) {
  errorType = 'rate_limit';
  action = 'retry';
}

// 資料庫連線錯誤 → 立即警報 + 通知 DevOps
else if (errorMessage.includes('database') || errorMessage.includes('connection')) {
  errorType = 'database';
  action = 'critical_alert';
}

// API 認證錯誤 → 通知相關負責人
else if (errorMessage.includes('unauthorized') || errorMessage.includes('401')) {
  errorType = 'auth_error';
  action = 'notify_owner';
}

// 使用者輸入錯誤 → 只記錄不通知
else if (errorMessage.includes('validation') || errorMessage.includes('invalid input')) {
  errorType = 'user_input';
  action = 'log_only';
}

return {
  ...originalData,
  errorType,
  action,
};

然後用 Switch 節點根據 action 來決定要執行哪些通知節點。

Q4: LINE 通知太多怎麼辦？如何設定通知冷卻？

A: 如果同一個工作流短時間內重複失敗，確實會造成通知轟炸。我的解決方案是加入「通知冷卻機制」。

方法一：用 n8n 的 Sticky Note（簡單版）

在 Error Workflow 加入一個 HTTP Request 節點，把上次通知時間存到你的資料庫或 Redis。然後在發送 LINE 通知前，先檢查距離上次通知是否超過 N 分鐘。

方法二：用 Google Sheet 記錄（無需額外服務）

// 在發送 LINE 通知前，加入這個 Function 節點

const workflowId = $json.workflowId;
const errorMessage = $json.errorMessage;

// 生成錯誤的唯一識別（工作流 ID + 錯誤訊息的前 100 字）
const errorHash = `${workflowId}_${errorMessage.substring(0, 100)}`;

// 從上一個節點（Google Sheet Lookup）取得上次通知時間
const lastNotifyTime = $('Google Sheet Lookup').first().json.lastNotifyTime;
const cooldownMinutes = 30; // 冷卻時間 30 分鐘

const now = new Date();
const shouldNotify = !lastNotifyTime ||
                     (now - new Date(lastNotifyTime)) > cooldownMinutes * 60 * 1000;

return {
  ...originalData,
  shouldNotify,
  errorHash,
};

然後用 IF 節點檢查 shouldNotify，如果是 true 才發送 LINE 通知。

我的建議冷卻時間：

Critical 錯誤 — 30 分鐘（避免短時間內重複通知，但不能太久）
Warning 錯誤 — 2 小時（不緊急，可以延長冷卻時間）
Info 錯誤 — 不通知，只記錄

Q5: Error Workflow 可以自動修復錯誤嗎？

A: 可以，但要看錯誤類型。有些錯誤是可以自動修復的，有些則不行。

可以自動修復的錯誤類型：

API Rate Limit — 等待一段時間後重試
暫時性網路問題 — 立即或延遲重試
資料格式錯誤 — 自動調整格式後重新處理（例如移除多餘空格）

不建議自動修復的錯誤類型：

資料庫錯誤 — 可能需要人工檢查
商業邏輯錯誤 — 自動修復可能造成資料錯誤
認證失敗 — 需要更新 Token 或密碼

自動重試的實作方式：

在 Error Workflow 加入以下邏輯：

// Function 節點：判斷是否可以重試

const errorMessage = $json.errorMessage;
const executionMode = $json.executionMode;
const retryCount = $json.retryCount || 0;
const maxRetries = 3;

// 只有特定錯誤類型才重試
const retryableErrors = [
  'rate limit',
  'timeout',
  'ECONNREFUSED',
  'ETIMEDOUT',
];

const shouldRetry = retryableErrors.some(keyword =>
  errorMessage.toLowerCase().includes(keyword)
) && retryCount < maxRetries && executionMode !== 'manual';

return {
  ...originalData,
  shouldRetry,
  retryCount: retryCount + 1,
};

然後用 IF 節點判斷 shouldRetry，如果是 true 就用 HTTP Request 節點呼叫主工作流的 Webhook 觸發重新執行。

這邊要特別注意：自動重試要小心設計，避免造成無窮迴圈或資料重複。我的建議是：

設定最大重試次數（例如 3 次）
加入延遲機制（例如第一次等 1 分鐘、第二次等 5 分鐘、第三次等 15 分鐘）
最終失敗後還是要發通知給人工處理

Q6: 如何分析 Google Sheet 的錯誤趨勢？

A: Google Sheet 累積一段時間後，就可以用來做錯誤趨勢分析。我會在 Google Sheet 加入第二個工作表「統計儀表板」，用函數自動產生報表。

實用的統計維度：

每日錯誤次數趨勢

=COUNTIF('Error Log'!A:A, "2025-04-30")

各工作流的錯誤率排名

=QUERY('Error Log'!A:H, "SELECT C, COUNT(C) WHERE C != '' GROUP BY C ORDER BY COUNT(C) DESC")

最常見的錯誤訊息

=QUERY('Error Log'!A:H, "SELECT F, COUNT(F) WHERE F != '' GROUP BY F ORDER BY COUNT(F) DESC LIMIT 10")

Critical 錯誤佔比

=COUNTIF('Error Log'!B:B, "Critical") / COUNTA('Error Log'!B:B)

執行模式分布（manual vs trigger vs webhook）

=QUERY('Error Log'!A:H, "SELECT H, COUNT(H) GROUP BY H")

這些統計數據可以幫助你：

找出最不穩定的工作流 — 優先優化錯誤率最高的工作流
識別系統性問題 — 如果某類錯誤突然增加，可能是外部 API 變更或 n8n 版本升級造成的
評估改進成效 — 優化後錯誤率是否真的降低了

我建議每個月看一次統計儀表板，把錯誤率高的工作流列入優化清單。

🎯 下一步行動

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

恭喜你看完這篇 n8n Error Workflow 的完整教學！如果你跟著步驟操作，現在應該已經建立了一個完整的錯誤監控系統，可以即時掌握所有自動化工作流的健康狀態。

接下來你可以：

立刻動手建立你的第一個 Error Workflow — 打開 n8n，跟著 Step 1-5 的步驟操作一遍，先求大概懂，再開始用，最後才能做成功
把現有的工作流都關聯到 Error Workflow — 特別是關鍵業務流程（訂單、金流、客戶通知），優先設定錯誤監控
觀看完整影片教學 — YouTube EP18 有完整的操作畫面，可以看我怎麼一步步設定三種通知方式
加入學習社群討論 — Skool 雲端方程式 Cloud F1 免費加入，和 500+ 學員一起交流錯誤處理的最佳實踐，很多人會分享自己的 Error Workflow 設計
下載免費模板 — GitHub 18-n8n-error-workflow 可以直接匯入我設計好的 Error Workflow，省去從零開始的時間
訂閱電子報 — 獲取最新的 n8n 自動化技巧和錯誤處理進階技巧

大家記得，錯誤處理不是「可有可無」，而是「必須要有」。你的 AI 自動化實力又變強囉！

有問題歡迎到 Skool 社群發問，我或其他學員都很樂意幫忙。希望這篇文章幫助你建立更穩定、更專業的自動化系統！

🔗 相關資源

內部資源

n8n 錯誤處理完整指南 — 更深入的錯誤處理策略和進階技巧
n8n 完整教學 2026 — 從零開始學 n8n，包含錯誤處理章節
n8n 實用技巧 1-16 集 — 16 個 n8n 實戰技巧，包含錯誤處理優化
8 分鐘學會 n8n 串接 LINE Messenger API — LINE 通知的詳細設定教學
n8n 自動化完整指南 2026 — n8n 自動化的完整學習路徑

外部資源

n8n Error Workflow 官方文件 — 官方的錯誤處理文件
LINE Notify API 文件 — LINE 通知的完整 API 說明
n8n Community Forum — 社群討論錯誤處理的最佳實踐
Zeabur n8n 部署模板 — 一鍵部署 n8n（推薦給新手）

影片教學

YouTube EP18 — 8分鐘學會 n8n 錯誤處理工作流 — 完整操作畫面示範
YouTube Playlist — 省力工具箱 — 50+ n8n 實戰教學

GitHub 資源

Error Workflow 免費模板 — 可直接匯入的完整 Error Workflow
n8n 自動化專案集合 — 更多 n8n 實戰專案和模板

本文改編自 YouTube 影片 EP18，由 Alex Hsieh 撰寫。如果這篇文章幫助你建立更穩定的自動化系統，歡迎分享給需要的朋友，讓更多人一起學習 n8n 錯誤處理！最後更新：2026-02-11

專業導讀

你將學到

🎯 什麼是 n8n Error Workflow？

💡 Alex 的實戰觀察

為什麼錯誤處理這麼重要，卻這麼容易被忽略？

三種錯誤通知方法的使用時機

老實說，Error Workflow 也有局限性

🔧 Step-by-Step 完整設定教學

Step 1: 建立 Error Workflow 基礎架構

實際操作步驟

Step 2: 設定 LINE 即時通知（Critical 錯誤）

實際操作步驟

Step 3: 設定 Email 詳細報告（Warning 錯誤）

實際操作步驟

Step 4: 設定 Google Sheet 歷史記錄（所有錯誤）

實際操作步驟

Step 5: 關聯主工作流到 Error Workflow

實際操作步驟

📊 比較分析：三種錯誤通知方法

我的推薦組合

✅ 重點整理

❓ 常見問題 FAQ

Q1: Error Workflow 會不會影響主工作流的執行速度？

Q2: 如果 Error Workflow 本身也失敗了怎麼辦？

Q3: 可以針對特定類型的錯誤，執行不同的處理邏輯嗎？

Q4: LINE 通知太多怎麼辦？如何設定通知冷卻？

Q5: Error Workflow 可以自動修復錯誤嗎？

Q6: 如何分析 Google Sheet 的錯誤趨勢？

🎯 下一步行動

🔗 相關資源

內部資源

外部資源

影片教學

GitHub 資源

相關文章

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

n8n 進階技巧 16-26｜Code 節點、錯誤處理到 Git 備份完整攻略

n8n 自動化完整指南 2026｜從入門到進階的終極教學