N8N Dead Letter Queue 深度解析：失敗件怎麼重跑
Dead letter queue 是 N8N 錯誤處理最實用的一層。這篇聚焦失敗件欄位、重跑流程、去重保護與人工介入，整理一套中小團隊也能落地的 DLQ 做法。
Dead letter queue 是 N8N 錯誤處理裡很實用的一層：主流程先往前跑，失敗件集中收納，再用補償流程重跑。
什麼情況該用 DLQ
最常見的現場是 webhook 已經進來、前半段也跑了，結果第三方 API timeout 或資料格式錯，整條 execution 直接變紅。沒有 DLQ，通常只剩人工翻 execution。
適合進 DLQ 的通常是訂單、付款、發票、會員權限、CRM lead、AI 批次摘要這類高價值資料；一次性測試資料、低價值通知、明顯無效的垃圾請求通常不必進。基礎擋法可先回看：https://n8nstart.cc/blog/n8n-beginner-complete-guide。
DLQ 至少要記哪些欄位
你不需要一開始就上複雜 queue 系統。對多數 N8N 團隊來說，先用資料庫表、Airtable、Notion database，甚至 Google Sheet 都能做。欄位至少要有：
- 唯一識別碼：
event_id、order_id、ticket_id - 原始 payload：補救時能還原現場
- 錯誤上下文：失敗節點、錯誤訊息、execution ID、失敗時間
- 重跑狀態：
pending、retrying、resolved、manual_review - 重試次數：
retry_count、next_retry_at
Workflow 要怎麼拆
主流程
主流程只做正常處理。高價值資料失敗時，把失敗件寫進 DLQ 就結束。
重跑流程
由排程觸發，撈出 pending 或已到 next_retry_at 的資料，再執行補償重跑。成功就標記 resolved，多次失敗就轉 manual_review。
告警流程
重試超過上限、涉及高價值交易、或碰到業務規則衝突時，直接發 Slack 或 email 給人處理。通知與分流場景可一起參考：https://n8nstart.cc/blog/n8n-automation-use-cases-5-scenarios。
兩個最常踩的坑
重跑成功了，但資料重複寫入
這是最大雷。重跑前一定要補 idempotency，例如先查唯一鍵是否已存在，已存在就直接標記 resolved。Webhook 場景可搭配看：https://n8nstart.cc/blog/n8n-webhook-trigger-essentials。
所有錯誤都拿去重跑
欄位缺漏、schema 不符、token 過期、業務規則不成立，不先修資料或設定，重跑只會一直失敗。暫時性錯誤排入重跑，其他錯誤轉人工。官方與 community 可交叉參考：https://docs.n8n.io/ 、https://community.n8n.io/。
一套中小團隊可直接照抄的設計
- 主流程失敗就寫入 DLQ 表，至少保留
record_id、payload_json、error_type、failed_node、retry_count、status。 - 排程每 15 分鐘跑一次補償流程，只撈
status = pending、next_retry_at <= now、retry_count < 3。 - 重跑前先做去重檢查，有資料就直接標記
resolved。 - 依錯誤類型分流：timeout / 429 / 503 可重跑，欄位缺漏與業務衝突轉
manual_review。
如果你的工作流有串 LLM，記得把 API 成本也算進重跑策略：https://n8nstart.cc/blog/n8n-ai-agent-complete-guide-2026。
結論
Dead letter queue 最有價值的地方，在於它讓主流程保持乾淨，也讓異常件有地方可去。對中小團隊來說，先把失敗件收好、可重跑、可人工接手，通常就能解掉大部分掉單問題。可直接看 N8Nmarket 模板庫 或回首頁：https://n8nstart.cc/。
FAQ
N8N 的 dead letter queue 一定要接 Kafka 或 RabbitMQ 嗎？
不用。對多數中小團隊來說，資料表或 Airtable 就能先做。
DLQ 跟 retry 有什麼差別？
retry 是同一條流程裡立刻再試一次；DLQ 是先把失敗件移到另一區，稍後再補救。
DLQ 重跑時怎麼避免重複寫入？
關鍵是唯一鍵與去重檢查。用 order_id、event_id 等識別碼，在重跑前先查是否已存在。
什麼錯誤不該進 DLQ？
低價值通知、測試資料、明顯無效的垃圾請求，通常不值得進 DLQ。